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Preface 



Methods, techniques, and practices for Enterprise Modeling have been a very 
important part of our professional lives during more than 15 years. We strongly 
believe that modeling is a key technique for understanding, capturing, and com- 
municating organizational knowledge — and crucial for successfully mastering 
change and innovation processes in enterprises. 

During the last years — when working on this book — we were involved in at least 
a dozen of Enterprise Modeling projects with different industrial enterprises or 
public authorities. In most of these projects it became obvious to us and other 
project participants that Enterprise Modeling methods and techniques are extremely 
valuable for understanding the present and preparing for the future — particularly in 
times of continuous organizational change, which is often caused by an increasing 
pace of innovation, collaboration with other organizations, new challenges in the 
market, societal changes, or technology advancements. 

The idea for this book emerged from discussions with our students. All of us 
regularly teach Enterprise Modeling at our respective universities and so far the 
teaching material for our courses consisted of an early version of a method 
handbook for the predecessor of the 4EM Enterprise Modeling method described 
in this book and a collection of lecture notes and slides also including enhancements 
of the method. Many students asked for additional, more comprehensive course 
material about the 4EM method, the techniques and practices related to it, and the 
field of Enterprise Modeling as such. This initiated nearly 2 years of work on this 
book with quite a few discussions about its scope and required content. Quite 
quickly we agreed to neither focus on theories and general approaches to Enterprise 
Modeling nor to try and cover all developments in the field. Instead, we decided to 
focus on practical advice and to combine a detailed description of 4EM with the real 
life experiences collected in our projects. The book addresses modeling procedure, 
modeling language, and modeling practices in an integrated manner. On the same 
topic, enterprise modeling with 4EM, a German language book is available. At first 
glance, the content of both books might seem similar. However, this English 
language edition has been substantially extended and revised as compared to the 
German book. 
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Preface 



When preparing the book we were surprised to learn how few books on Enterprise 
Modeling methods were published and that even fewer have a focus on how to do 
Enterprise Modeling in practice. A reason for this might be the large number of books 
on business process management, process modeling, and process optimization. Pro- 
cess modeling and Enterprise Modeling are often considered as different words for the 
same subject, but they definitely are not the same for us. Enterprises consist of much 
more than processes and hence modeling and managing only processes will not 
provide a complete and holistic understanding of the enterprise, which is required 
for properly addressing many challenges and problem-solving tasks. 

This book would not have become a reality without the support of many people 
in our private and professional environments. First of all, we would like to thank all 
colleagues and friends who actively contributed to the development of 4EM and its 
predecessor, EKD. Since the list of people would be very long and the danger 
imminent that we would forget someone, we just want to mention Prof, emeritus 
Janis Bubenko Jr. at the Royal Institute of Technology (Sweden), Prof. Pericles 
Loucopoulos at Harokopio University of Athens (Greece), and Prof. Colette Rol- 
land at Universite Paris 1 Pantheon — Sorbonne (France) who all were part of 
developing the first versions of what now has developed into the 4EM method. 

Furthermore, we would like to thank our colleagues in Jonkoping, Riga, Ros- 
tock, Skovde, and Stockholm who teach Enterprise Modeling, use 4EM or EKD, 
and contributed ideas, improvement proposals, and practices in many fruitful 
discussions and joint modeling sessions. You all know who you are! 

Moreover, we would like to thank fellow researchers and practitioners that work 
in the area of Enterprise Modeling and in recent years have been part of forming an 
active community under the auspices of the IFIP Working Group 8.1 on Design and 
Evaluation of Information Systems and more specifically the Working Conference 
on the Practice of Enterprise Modeling (PoEM). Many ideas presented in this book 
have been put forward for discussion with our peers at these forums. 

Furthermore, we would like to thank Prof. Ulrich Frank at the University of 
Duisburg-Essen (Germany), Prof. Dimitris Karagiannis at the University of Vienna 
(Austria), Frank Lillehagen at Commitment AS (Norway), and Prof. John Krogstie 
at the Norwegian University of Science and Technology for checking the content of 
Chap. 14. 

We acknowledge the support from our research groups and colleagues in 
Rostock, Skovde, and Stockholm. We are particularly grateful to Ulrike Borchardt, 
Petra Kegler, Hasan Koc, Birger Lantow, Dirk Stamer, Peggy Sterling, Tino 
Weichert, and Tino Weigel for their help in creating pictures and with formatting, 
cross-referencing, proofreading, and establishing the companion Web site. 

The last months before finishing the book have been a challenge to our families. 
We would to thank them for all the support and understanding. 

Rostock, Germany Kurt Sandkuhl 

Stockholm, Sweden Janis Stirna 

Skovde, Sweden Anne Persson 

Rostock, Germany Matthias WiBotzki 

May 2014 
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Chapter 1 

Introduction 



Many systems and organizations seem complex and difficult to understand — until 
you show their elements and structures and reveal relations and dependencies. 
Enterprises are such complex systems with their different organizational units and 
people working in the enterprise, with workflows and production processes, prod- 
ucts and services offered to different customer groups, supplies and business 
partners, IT systems and production resources, etc. This book is about Enterprise 
Modeling, a technique that helps to capture the different elements and structures of 
an enterprise as well as to visualize the inter-dependencies between the elements. 
Enterprise Modeling can be used for a multitude of different purposes, like visual- 
izing the current situation, analyzing the reasons for shortcomings or problems, 
developing strategies for business or IT, optimizing processes, or setting up new 
cooperations with other enterprises. 

Enterprise Modeling offers a practical and flexible set of work procedures, tools, 
and practices, which can be adapted to the situation at hand and to the purpose in 
focus. One of the main purposes of this book is to provide a “guide for action,” 
i.e., practical advice for how to address challenges in enterprises which can be 
solved or supported with Enterprise Modeling. The methods, tools, and practices 
provided by the book are rooted in experience from many industrial modeling 
projects, but they also have a solid theoretical foundation from research in the field. 

Enterprise Modeling is a structured way of working which captures various 
perspectives, such as goals, processes, and actors, of an organization or a problem 
situation in an integrated way. It supports management of the organization by 
supporting change management, decision making, and planning processes both 
within the different business functions and for the IT support. 

Enterprise Modeling has a strong connection to the discipline of Enterprise 
Engineering, which aims at providing methods and techniques for an aligned 
development of all parts of an enterprise, e.g., the business, functional, organiza- 
tional, and technical aspects. Such an aligned development is far from trivial, since 
the business environment and the IT in an enterprise continuously change, but the 
pace of change and the time frames needed to implement changes are different. 

© Springer-Verlag Berlin Heidelberg 2014 1 
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1 Introduction 



Enterprise Engineering combines concepts from management and organization 
science, information systems science, and computer science to achieve this goal. 
The core ideas of enterprise engineering, from the perspective of the CIAO! 
network (http://ciaonetwork.org/), are defined in the Enterprise Engineering Mani- 
festo (Dietz 2011). The manifesto includes seven postulates aiming at achieving 
practical relevance and theoretical rigor in enterprise engineering. 

In some areas of economics, the term “enterprise” is used for the private sector 
enterprises only. However, this book’s interpretation of Enterprise Modeling is not 
limited to any specific kind of enterprise. It is applicable to public organizations, 
industrial enterprise of any domain, privately run businesses, as well as any kind of 
nonprofit association. The term could as well be “organization modeling” but 
Enterprise Modeling is more established. 

Furthermore, Enterprise Modeling does not always have to consider the com- 
plete enterprise, it may focus on those parts of the enterprise or organization that are 
subject to investigation. The scope of a modeling project is usually defined in the 
early phases of modeling. 

Enterprise Modeling is related to a number of other modeling disciplines, like 
business modeling, business process modeling, or information modeling. Business 
process modeling and Enterprise Modeling are similar in that both capture and 
visualize the relevant business processes with the actors involved and resources 
needed. However, in Enterprise Modeling business processes are only one view of 
the enterprise and not the predominant one like in business process modeling. 
Enterprise Modeling can support different modeling purposes, which leads to a 
greater flexibility of the methods; some application areas of Enterprise Modeling do 
not require detailed process modeling. 

Similarly, information modeling and Enterprise Modeling have some overlap. 
Information modeling aims at identifying information objects with their attributes, 
which often is a part of enterprise models as well. Information models are used in 
information systems or software development and have to be very detailed whereas 
enterprise models include information objects to capture relationships and depen- 
dencies, which usually do not require the same level of detail. 

Enterprise Modeling and business modeling are often used as synonyms. Busi- 
ness modeling is in principle a broader term consisting of a wide range of 
approaches originating in operations research, economics, management studies, 
and information systems. 

In summary, Enterprise Modeling as described in this book has two main 
characteristics: (1) it focuses on addressing multiple perspectives of an enterprise 
in an integrated way and (2) it offers a set of practical guidelines for knowledge 
acquisition, modeling, and analysis. In addition, the stance taken in this book 
concerning the modeling process is that the quality of models and the effect of 
modeling are greatly enhanced if a participatory approach to stakeholder involve- 
ment is adopted. 



1.1 Goal of the Book: Practical Advice 
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1.1 Goal of the Book: Practical Advice 

The main goal of this book is to provide practical advice on Enterprise Modeling 
(EM). The theoretical background to EM also is part of the book, but it is limited to 
the most relevant concepts. EM is a powerful technique for many application 
purposes if used in the right way with the right aids and resources. The approach 
in this book to providing practical advice is to start from common challenges in 
enterprises and offer a flexible EM method suitable for tackling the challenges. 

The practical challenges are common situations that occur in enterprises and 
have the potential for cost savings or efficiency improvement if managed correctly 
and are beyond the normal day-to-day activities of running the enterprise. Such 
challenges are often connected to midterm or long-term enterprise development, 
e.g., organizational structure development, quality and process improvements, 
strategic development, as well as innovation processes. 

This book offers an EM approach for tackling these challenges. It is flexible in 
the following ways: 

• It does not have a rigid problem solving process. Instead, the way of working 
(the modeling process) can be adjusted to the situation at hand depending on the 
enterprise’s preferences and on the preferences of the problem solver. 

• The modeling language suggested consists of various components for modeling 
the different perspectives (e.g., goals, business processes, concepts), which — 
like in a toolbox — can be combined and applied in many different ways. 

• All parts of the approach are freely available and not locked behind consultancy 
secrets. 

The practical challenges are discussed in Chap. 2, the modeling language in 
Chap. 8 and the modeling process in Chap. 9. In addition to giving advice on how to 
use EM for tackling business challenges, the book also includes advice on areas 
related to EM, e.g., elicitation techniques, reference models for enterprise architec- 
tures, how to do quality validation of models, and how to run EM as a project. 

Much of the work presented in the book originates from research projects and 
has been validated with scientific methods. It has also been successfully applied in a 
large number of development and/or change management projects in industry and 
in the public sector. The experiences from these projects provide a solid basis for 
this book. 

When using EM for tackling business challenges, method knowledge alone is 
not enough. EM activities also require a solid project organization in order to 
achieve the desired results, i.e., resources need to be secured, roles assigned, and 
decision structures prepared. We provide recommendations for setting up an 
adequate project organization in Chap. 9. 
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1 Introduction 



1.2 Structure and Content 

The aim of this book is to provide practical advice on how to successfully carry out 
EM, particularly by using the 4EM method for Enterprise Modeling. This aim is 
also reflected in the structure of the book: 

Chapter 2: This chapter will show how EM can help tackling typical business 
challenges that practitioners face in their daily work. The common characteristics 
of the challenges and how 4EM should be used to address them are described. The 
challenges are the need to understand organizational dependencies, find the need for 
change, improve business processes, align organizational strategy and IT, as well as 
develop the IT strategy. 

Chapter 3 introduces important terms and concepts used throughout this book — 
models and their purpose, modeling language and modeling process, as well as 
basic components of an Enterprise Modeling method used in this book. 

Chapter 4: One of the central elements in EM is analyzing the actual situation 
and existing challenges in the enterprise in close cooperation with domain experts, 
decision makers, and other stakeholders in the enterprise. In this context, elicitation 
approaches including interviews, observation, document analysis, and participatory 
modeling sessions are important skills for the modeler. This chapter introduces the 
most frequently used elicitation approaches. 

Chapter 5 focuses on EM tools. Relevant tools do not only include IT-based 
applications, but also traditional aids, like flip charts and the “plastic wall.” Even 
though IT-based tools are subject to continuous development and improvement, a 
number of core features can be identified which many modeling tools offer. This 
chapter will introduce different tool categories including an example for each 
category. 

Chapter 6: An example case used for explaining the 4EM concepts is introduced 
in this chapter. The case study is about an imaginary company from the retail sector 
with several subsidiaries and substantial e-Commerce activities. 

Chapter 7 introduces the 4EM method by giving an overview to three main parts 
of the method — a defined work procedure and notation, the participative approach 
to stakeholder involvement, and the organization of EM activities as projects. 

Chapter 8: The 4EM method includes six integrated sub-models addressing 
different perspectives of the organization. For each sub-model, the purpose of the 
model, notation, components, an example from the case study, development pro- 
cess for the sub-model is presented. 

Chapter 9: For an EM project to succeed, knowledge of the basic elicitation 
approaches and EM perspectives is necessary, but not sufficient. Establishing an 
EM project in the organization and carrying out the EM process are equally 
important aspects. This chapter describes how such a modeling project should be 
structured and established. This includes the roles within the project team, organi- 
zational frame conditions, and typical project phases. 
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Chapter 10: The success of EM projects also depends on having personnel with 
the right competences in the project team. This chapter discusses issues of compe- 
tence supply. 

Chapter 11: Organizations usually begin using EM in a project form where an 
outside vendor and/or consultant provide the method and tool usage competence. If 
they use EM sufficiently frequently a need to use EM without external support often 
arises. This chapter discusses the process of how to acquire an EM approach and a 
tool in order to use it without the support of outsiders. More specifically, this 
chapter discusses the acquisition and adoption processes as well as organizational 
structure needed to support EM activities. 

Chapter 12: EM projects and the cooperation process between different stake- 
holder groups sometimes result in organizational change measures which can be 
implemented without initiating bigger change projects or the introduction of IT 
support. In such cases, the different models developed might only be used for 
documentation purposes. However, in the majority of the EM projects, the 
sub-models will be continuously refined, improved, and transformed; they need to 
have a high-quality level. This chapter discusses the overall principles of enterprise 
model quality as well as suggests a number of best practices for improving model 
quality. 

Chapter 13 addresses the two aspects of reuse in EM — developing reusable 
model fragments (design for reuse) and reusing existing reusable components in 
building new models (resign with reuse). The main focus of the chapter is on the 
concept of patterns as the main medium for supporting reuse. 

Chapter 14 introduces a selection of EM and business process modeling methods 
that show similarities to the 4EM method. The purpose of this chapter is neither to 
provide an exhaustive list of approaches nor is it to include all details and usability 
aspects of these approaches. The intention is rather to show that 4EM in many 
aspects is a typical or exemplary modeling language, i.e., it is easy to switch from 
4EM to another method, since most concepts and perspectives used in 4EM also are 
to some extent available in other methods. 

Chapter 15: Within the field of EM, substantial work has been spent on defining 
frameworks and architectures. In comparison to EM methods, frameworks and 
architectures do not focus on procedures for the actual modeling process, notations, 
and modeling languages, but they address the modeling domain or the results of the 
modeling process. Most frameworks were developed within a specific application 
domain or for an enterprise function and structure this domain and function. This 
chapter introduces frequently used reference models and discusses their relevance 
and application potential for enterprise modeling. 

Chapter 16 discusses the current research trends and directions for further 
studies. This includes the connection between EM and information system devel- 
opment, and in particular the field of Requirements Engineering, the area of 
enterprise architecture management, linking EM and Model Driven Development, 
and support for mobile and cooperative modeling. The main objective of the 
chapter is to give advice to the reader on which additional subject area and material 
could be of interest. 



6 



1 Introduction 



1.3 Reading Recommendations 

This book is written for everybody who wants to learn more about EM with specific 
focus on how to do it in practice and how to teach it. Although the book does not 
require any prior knowledge about EM, background knowledge in how an enter- 
prise functions and the basics of modeling in general is recommended. 

Basic modeling knowledge, like how to develop an information model, is 
recommendable since abstracting the most important aspects from reality in order 
to capture these aspects in a model is also at the heart of EM. 

General knowledge about structures and processes in organizations helps to 
understand the method description in this book and applying the method constructs 
to reality. 

More specifically, the book is written for four main target groups: 

• Instructors in the field of Enterprise Modeling, 

• Students in the areas of information systems, computer science, and business 
administration, 

• Newcomers in the field of Enterprise Modeling, and 

• Practitioners looking to extend their competence and to get practical advice for 
tackling their business problems. 

Newcomers to Enterprise Modeling. Newcomers need to understand what EM is 
for and where its limits are and that an enterprise should be viewed from different 
but integrated perspectives in order to fully understand dependencies, how to start 
an EM activity, and the actual way of modeling relevant facts and using the model 
for the purpose at hand. The reading recommendation in this case is: 

• Start with Chap. 2, which will provide a number of typical examples where EM 
is useful. There is no need to study all of the content of Sect. 2.1 in detail, but 
reading at least some Sects, of 2.1 (practical challenges) plus 2.2 and 2.3 is 
recommended. 

• Chapter 3 introduces important terms in EM. You can either go through it at the 
beginning or use it as reference section for checking the meaning of terms. 

• Chapter 4 contains valuable information about how to elicit knowledge from the 
problem domain by various approaches such as interviewing, observing stake- 
holders, studying documents, and performing participatory modeling sessions. 
The content of this section is very important for practical modeling, but it does 
not strictly originate from Enterprise Modeling, i.e., you might have learned it 
elsewhere. 

• Chapter 6 introduces the case study used for illustrating the modeling tech- 
niques. Read at least Sect. 7.1 to get an idea of the case and revisit other parts of 
Chap. 7 when using the examples in Chap. 8. 

• Chapter 7 is important because it shows how the modeling method (Chap. 8), the 
project organization (Chap. 9), and the participative way of working (Sect. 9.6) 
complement each other. 



1.3 Reading Recommendations 
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• Chapter 8 should be studied in great detail. Here, you will learn the different 
views of an enterprise, how to capture them, and what questions to ask. For each 
perspective, you should take some time to inspect the examples. 

• Chapter 9 complements the knowledge of “how to model” with knowledge about 
“how to start” in an enterprise and how to set up modeling projects. 

In order to have most use of it, newcomers to the subject should study the 
remaining sections of the book only after gathering some practical modeling 
experience first. 

Practitioners Practitioners will probably use the book in different ways, depending 
on the situation of use. On the one hand, the book can be used as reference manual 
for reading up on subjects of interest to the practitioner. Elicitation approaches, EM 
methods and perspectives, reference frameworks, or quality assurance are among 
the subjects covered in chapters that can be studied independently of the other book 
chapters — if the background knowledge is sufficient. 

On the other hand, the book provides instructions on how to approach problem 
solving for business challenges (some of them outlined in Sect. 2.1). The challenges 
all include information about the EM perspectives important for tackling the 
challenges and the tools or subject matter experts needed. With this information, 
the reader can proceed to Chap. 7, which explains the different elements of a 
successful EM activity. Afterwards, Chap. 8 is important, where each modeling 
perspective and its use is presented in a cookbook style, including which questions 
to ask and what information to look for. Chapter 9 provides information on how to 
set up an EM project and Chap. 5 provides advice regarding tools available while 
Chap. 12 discusses aspects of model quality. 

Instructors Instructors will find the material in this book suitable for different 
levels of courses and different study programs. The book serves as a basis for 
education on Bachelor-, Master-, and PhD-course level. In the following, a proposal 
for both Bachelor and Master level courses is presented. Additional information, 
lecture slides, and other teaching material are available on the book’s companion 
website (See http://www.4em-method.com). 

For a course on Bachelor level a lecture track in parallel to a lab track with 
exercises in EM is recommended. The lecture track could consist of the following 
parts: 

• An introductory session about EM and typical application cases based on 
Chap. 2 and examples from the case study in Chap. 7 

• One or two lectures about knowledge elicitation techniques presented in Chap. 4. 
To what extent this subject has to be addressed depends on whether it is covered 
elsewhere in the study program. 

• One lecture about the basic terminology in EM based on Chap. 3 

• 2-3 lectures about the different EM perspectives, how to approach them, and 
what notation to use. This part should be based on Chaps. 7 and 8 
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• One lecture about the case study used in the book, or alternatively, the case study 
used for the lab work. Alternatively the students can be allowed to choose their 
own case. 

• One lecture about the quality characteristics and validation of enterprise models 
based on Chap. 1 1 

• One lecture about setting up and organizing Enterprise Modeling projects based 
on Chaps. 9 and 10 

• One lecture about how to use the enterprise models produced for process 
improvement and information system development. 

The lab part should primarily consist of performing EM for a given purpose in a 
sample case using all perspectives. Such a course should be scheduled after 
fundamentals of business administration and basics of information or process 
modeling. 

On the Master level, method knowledge, knowledge about tools, reference 
architectures, and quality aspects can be in focus. Chapters 5 and 11-15 can serve 
as a basis for lectures introducing these subjects and as study material for the 
students. Most chapters contain recommendations for future readings, which pro- 
vide starting points for assignments to students. 

Students If you intend to study by yourself, you should study the content of the 
book according to the sequence of its chapters. If the book is used as part of a course 
or study program, the instructor will provide advice on how to proceed. 



Chapter 2 

Business Challenges: And How Enterprise 
Modeling Helps 



Enterprises operating in most industrial and service sectors face a number of 
business challenges that exceed the scope of the daily operations and routine 
activities. Examples are continuous process improvements for increased efficiency, 
adjustments of the enterprise strategy to new market demands, changing business 
models due to new competition, new regulations and bylaws requiring operational 
changes, or technological innovations leading to changed customer behavior and 
new processes. In many cases, improving business processes alone is insufficient 
for addressing problems of this nature. The overall situation of the enterprise has to 
be taken into account including relations between strategic goals, business rules, 
work processes, organization structures, products, services, IT infrastructure, etc. 

Enterprise Modeling (EM) is a proven instrument for addressing these kinds of 
organizational challenges. The area of Enterprise Modeling in general is concerned 
with techniques, methods, and tools for modeling organizations and for finding and 
preparing potential improvements. This chapter discusses a number of typical 
business challenges for illustration purposes (Sect. 2.1) and then shows how EM 
can help addressing them (Sect. 2.2) followed by an overview on practical guidance 
for modeling (Sect. 2.3). 



2.1 Typical Business Challenges 

The aim of this chapter is to discuss a number of typical business challenges in 
order to show how EM can help in tackling them. The following challenges will be 
discussed: 

• Understanding organizational dependencies 

• Finding the need for change 

• Improving business processes 
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• Aligning organizational strategy and IT 

• Developing the IT strategy 

The challenges will be described in terms of their typical characteristics and put 
in relation to the EM perspectives with respect to why and to what extent they are 
needed to understand the problem and to define a solution. Method support for the 
different perspectives will also be presented in this chapter. 



2.1.1 Understanding Organizational Dependencies 

Many situations and tasks in enterprises require a clear understanding of the 
established organizational structures and existing processes, which can be achieved 
by creating enterprise models to visualize these structures and processes. Such a 
visualization describes the current situation in the enterprise and helps to clarify 
relations and dependencies between various parts of the organizational design. 
Visualizing the current situation usually is the first step towards finding problems 
(discussed in Sect. 2.1.2.) and improving business processes (see Sect. 2.1.3.), but it 
can also be applied for other purposes, such as: 

• Training new employees and introducing them to the current practices of an 
enterprise. This activity can benefit from documentation that includes enterprise 
models. The focus of the documentation will often be on the workflow, e.g., 
standard operation procedures, and on tasks and responsibilities, e.g., which role 
or unit in an organization is responsible for what task. 

• Planning a new product variant or customer service. In such cases it is important 
to know the dependencies between new and existing variants of products and 
services as well as which processes and resources are involved in production. 

• Identifying dependencies of the information systems and IT applications in an 
enterprise and analyzing the IT support for different tasks and work processes. 
Visualizing these relations is an important input for planning operations and 
maintenance. 

• Setting up the cooperation with a new partner or supplier. In such cases EM is 
instrumental in showing the business processes that the new partner or supplier 
will be contributing to and hence what integration activities need to be designed. 

The above examples show that visualization of the enterprise may focus on 
different views of the enterprise, like processes, IT systems, services, or organiza- 
tion structures to serve the specific purpose for the EM activity. 

One of the most important features of enterprise models used for visualization 
purposes is that they have to be easy to understand for the targeted users. This 
includes a modeling language that is easy to understand and is adequate for the 
purpose, tool support for easy navigation in the models, as well as a layout of the 
models supporting illustration of relationships and dependencies. 

Furthermore, such models have to reflect the current situation in the enterprise or 
part of the enterprise under consideration, i.e., accuracy to the required level of 
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Table 2.1 Features of EM for understanding organizational dependencies 



EM for understanding organizational dependencies 



Purpose 


Capture and document organizational aspects, such as structures and 
processes, in an explicit and understandable form 


Input required 


Scope: which part of the enterprise has to be considered (organization 
units, processes, divisions, etc.)? 


Who should be 
involved? 


Staff knowledgeable about the problem domain from all levels (opera- 
tions, management, subject matter expert) 


Typical outcome 


Enterprise model for the part of the enterprise depending on subject and 
purpose: process, organization structure, IT systems, products 


Critical quality 
issues 


Model has to fit the reality (high correctness) 

Modeling language and the produced models have to be easy to under- 
stand for organizational stakeholders (high understandability) 


Tool support 


Viewing and browsing of models 



details is essential. In order to achieve the desired level of accuracy subject matter 
experts (stakeholders) with deep knowledge of the problem domain should be 
involved in modeling. 

Formality of the models usually is less important since the models are not meant 
for using them in workflow engines or other execution environments, but only for 
human audience. 

That the purpose of modeling is the visualization is often known from the 
beginning and the scope of the model is quite clearly defined. More often in such 
cases, a top-down modeling strategy is applied, i.e., starting with the general 
structures and processes and elaborating details in increments. Table 2.1 summa- 
rizes the characteristics of enterprise models and the modeling process for visual- 
ization purposes. 



2.1.2 Finding the Need for Change 



Daily work in most enterprises does not only consist of running routine processes or 
standard procedures in a “business as usual” fashion; it also includes troubleshooting 
and as well as identifying the need for and developing improvements. Problems 
are often related to several areas of the organization, e.g., different processes, 
products, organization units, and systems. Finding and analyzing them requires 
an understanding of the dependencies and relationships, which is often difficult 
because they are hidden in the complexity of the enterprise. In some cases the 
symptoms of a problem are visible, but the causes remain hidden and require a 
careful analysis. 

EM can help finding such problems or — to be more precise — finding and 
analyzing them in order to identify their causes and potential solutions. Depending 
on the visible effects of the problem, different aspects of the enterprise might have 
to be modeled. Examples are: 
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• Variations in the quality of products or services could have their cause in 
different opinions of stakeholders in the organization about what the most 
important quality aspect is. Even though standard procedures might be defined, 
the quality will depend on who is involved and maybe even on the sequence of 
the involvement. This is difficult to detect unless quality priorities are made clear 
and the different viewpoints are exposed. 

• In many enterprises problems in the information flow cause costly operational 
problems, such as high failure rates in production and delayed deliveries. In such 
situations, all roles involved in a process should, in principle, get the right 
information for their task but in reality the information is partially incomplete 
or inaccurate without the stakeholders being aware of this. 

• Process descriptions are interpreted and followed differently at different parts of 
the same enterprise, which causes deviations in resource use and process effi- 
ciency. The differences in executing the same business process can be caused by 
specific changes at some of the parts of the organization, which makes the 
existing process descriptions incomplete. Explanations for these deviations 
will require creating a joint view of the process by all involved sites. 

• Organization finds itself in a changing market situation and needs to adjust its 
business vision and how the vision is implemented. In such cases the business 
vision is created and the existing business processes and the IT architecture need 
to be adjusted as well as new components need to be introduced. 

• Different interpretations of the same term or business concept can have an effect 
on how policies and business rules are handled in an enterprise. Clarification of 
such terms may seem as an easy task on the outset, but connecting this to 
operational problems often requires a substantial effort. 

When dealing with these kinds of “wicked” problems it is important to have a 
problem solving approach which is not too rigid in its process but allows for 
adaptation to the situation at hand. Different ways of gathering information about 
the situation might be needed, e.g., moderated modeling sessions, observations, and 
interviews. At the same time, different perspectives need to be analyzed in order to 
identify dependencies between the various aspects of the problem situation. This 
may entail creating and analyzing a combined process and service view or consid- 
ering the involved organization units from the perspective of their position in the 
value chain. One of the key factors for finding the problem is to include those 
people in the problem solving process who are involved in daily operations of the 
area in question. Those who are only responsible for operations might not be 
sufficient because they might only know how things “should be performed” and 
not how they are really done in practice. Table 2.2 summarizes features of EM for 
finding the need for change. 
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Table 2.2 Features of EM for finding the need for change 



EM for finding the need for change 



Purpose 


Find the needs for changing the organization 


Input required 


Where is the problem encountered? How does the problem manifests for 
itself? Who is involved (staff, role, unit, . . .)? 


Who should be 
involved? 


Stakeholders familiar with the problem on operational and managerial 
levels 


Typical outcome 


Problem analysis in terms of which organization unit, role, process, 
product, IT system, or information is involved, what are the likely causes, 
what needs to be done to solve them 


Critical quality 
issues 


Model has to include the dependencies between different potential aspects 
and effects of the problem 


Tool support 


Capturing different perspective in the same model 



2.1.3 Improving Business Processes 



Efficient and effective processes are one of the keys to a successful business. If 
processes do not fulfill this criterion they need to be improved. This is a challenge 
that many enterprises face and EM is able to support it. 

Process improvement projects usually start from an observation that certain 
activities or workflows in an organization take too much time or resources, that 
they produce suboptional results, or that they are performed with many ad hoc 
adjustments and work-arounds created by the involved staff members. Thus, the 
starting point for process improvements is often given by such observations. 
However, when defining the scope for the improvement project a wider view should 
be taken in order to include potential influences from related process and/or 
departments. The potential improvements will most likely concern more areas 
than just processes. It is highly likely that business goals, concepts, business 
rules, and the IT infrastructure will also have to be changed. 

Process improvement has to usually involve three different levels that can be 
supported by EM: 

• The strategic level concerns the definition of the objectives from an enterprise 
perspective to be reached with process improvements. Questions to consider are: 
is it more important to shorten the time needed for completing the process, to 
reduce the resources needed, or to increase the number of parallel process 
executions; should the improvement contribute to increased customer satisfac- 
tion or is the priority on standardizing process execution? 

• The conceptual level addresses the design of future processes in accordance with 
the strategic objectives of the organization. This includes aspects like the flow of 
activities, the personnel involved, the resources needed, interfaces to related 
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processes, etc. An important aspect is to agree with the subject matter experts 
and the staff involved on the future process in order to increase acceptance of the 
process. 

• The operational level implements the results from the conceptual level for 
everyday use in the enterprise. This can be achieved by using workflow envi- 
ronments for process execution or specific IT support. The step from the 
conceptual level to the operational level often requires refining the processes 
(e.g., by describing all possible exceptions from the standard process) and 
adding more details. 

EM is well suited for the strategic and the conceptual level. Here, visualizing and 
defining objectives and processes, creative design of future situations, and agree- 
ments between stakeholders are more important than exact technical specifications 
and “executable” process descriptions. For the operational level, many specific 
workflow languages and execution environments were developed, which fit better 
to the purpose of implementing the process. However, these specific workflow tools 
often have shortcomings in supporting the creative and design part of the process 
improvement. EM can also be used for more exact operational specifications of the 
conceptual level, but since it is not meant for process execution, different modeling 
languages may need to be used. 

The typical outcome of a process improvement project in the first stage is an 
inventory of the most important processes with a short textual description but without 
detailed specification of the activity flow. The processes to be improved have to be 
defined in more detail including the sequences of activities, alternative activity flows, 
actors, and resources involved. The future process descriptions should be captured as 
visual models and agreed on between the stakeholders involved. 

Table 2.3 summarizes the feature of EM for process improment. 

Table 2.3 Features of EM for process improvement 



EM for process improvement 



Purpose 


Improving business processes 


Input required 


Processes to be improved including the relevant actor dependencies, such 
as the process owner 


Who should be 
involved? 


Management level for defining strategic objectives; process owner and 
involved staff for designing future processes; operations manager and 
technical support for process implementation 


Typical outcome 


Strategic objectives guiding process improvement; future process with 
roles, resources, and supporting IT; action plan for implementing the 
change process 


Critical quality 
issues 


Fulfillment of strategic objectives; feasibility of future process in practice; 
acceptance by staff involved; integration with other processes and systems 
in the organization 


Tool support 


Modeling of processes at several levels of abstraction, using the process 
decomposition principle 
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2.1.4 Aligning Organizational Strategy and IT 



Alignment of business and IT is often considered to be a serious challenge in 
enterprises since the business environment and organizational practices continu- 
ously change and in turn so does the IT of an enterprise. The pace of change and the 
time frame needed to implement the changes are different in both areas. Further- 
more, business professionals and IT professionals often have different back- 
grounds, use different terminology, and set different priorities for development. 
In this context of multitude of influences and contradicting needs, reaching an 
agreement about how to set priorities for the enterprise is difficult, because there is 
no enough understanding of the “other side.” EM is able to deal with situations 
where different stakeholder views and requirements need to be consolidated and 
consensus achieved. For the purposes of business and IT alignment, the following 
directions of work are commonly taken: 

• Goal modeling and problem modeling involving business and IT professionals in 
order to create a better understanding for the concerns, limitations, and priorities 
from a business or an IT perspective. In particular, using a participatory way of 
working consisting of modeling sessions leads to creating common understand- 
ing of dependencies between goals and problems as well as resolution of 
inconsistencies and conflicts between the goals, the measures for reaching 
them, as well as the IT requirements and architecture design. 

• For the most important future business areas or the most relevant strategic 
developments, the dependencies between products or services and IT can be 
modeled as well as the dependencies between the core business processes and IT 
systems can be visualized. Knowledge about these kinds of dependencies will 
help to plan the forward development of IT proactively and to influence the 
priorities that are assigned on the business side. 

• In cases when business and IT development is congruent EM is used to elaborate 
and compare different strategies for achieving the business intentions. 

For all of the above purposes it is important to involve business and IT pro- 
fessionals responsible for the areas under consideration and for implementing 
business or IT changes. This kind of stakeholder involvement increases acceptance 
of the designed solution and reduces potential tensions during implementation and 
deployment of the solution. 

With respect to the modeling language and the tool to be used, the stakeholders 
should not be forced to leam new languages or to get acquainted with modeling 
tools, since this might negatively affect their willingness to participate in the 
modeling process. Enterprise- wide modeling tools and languages that are already 
used within the organization should be applied to ensure compatibility with the 
existing designs and solutions. If the organization does not have experience with 
EM and/or other model-based ways of working, less formal approaches and easy- 
to-use tools, like modeling on large plastic sheets, should be preferred. In many 
cases, the actual models produced will be less important than the process performed 
and the agreements or advances reached during the process. Table 2.4 summarizes 
the features of EM for aligning business and IT. 
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Table 2.4 Features of EM for aligning business and IT 



EM for aligning business and IT 



Purpose 


To achieve congruence of business and IT 


Input required 


Business challenges and IT challenges to be coordinated. Existing busi- 
ness visions and designs, existing IT architecture 


Who should be 
involved? 


Business and IT professionals responsible for the areas under consider- 
ation or for implementing business or IT changes 


Typical outcome 


Examples: joint understanding of business and IT regarding goals and 
problems; dependencies between products/services and IT; comparison of 
different solution alternatives 


Critical quality 
issues 


Joint understanding of business and IT professionals regarding problems, 
goals, and dependencies, integration of models 


Tool support 


Depending on the actual purpose, e.g., support for requirements manage- 
ment, integration with IS development tools (e.g., CASE or MDD tools) 



2.1.5 Developing the IT Strategy 



In general, an IT strategy defines the long-term objectives that the IT in an 
enterprise is supposed to reach in order to contribute to the enterprise strategy as 
well as the measures and planning for reaching these objectives. Depending on the 
importance of IT for the enterprise and on the size of the enterprise, an IT strategy 
can be quite complex and encompass strategic, tactical, and operational parts. EM is 
well suited to support developing the strategic and tactical levels and can even 
contribute to the operational level. 

On the strategic level the organizations formulate the goals to be reached in the 
long term and the problems to be solved. A prerequisite for this task is to have a 
clear picture of the current situation of the IT and its support of the enterprise 
operations. The current state of affairs can be modeled as described in Sect. 2.1.1 
“understand organizational dependencies.” However, the enterprise application 
architecture, i.e., the different IT applications and information systems including 
their interfaces, and the IT infrastructure (servers, networks, locations, etc.) have to 
be in focus of modeling. This should also include the IT support for the core 
business processes and functions, e.g., what roles and business processes use 
which applications or information systems. Based on the knowledge about and 
the analysis of the current situation the existing problems and aims for the future IT 
of the organization can be identified and made explicit. This task should include all 
enterprise stakeholders involved in defining and implementing the strategy. The 
stakeholders to be involved are the IT Management of the enterprise, representa- 
tives of the corporate management, and representatives of the different divisions 
and business lines in the enterprise. An important input for this process is the 
overall “corporate” strategy for the enterprise or, alternatively, long-term objec- 
tives/challenges of the enterprise from business perspective. If the corporate strat- 
egy is not explicitly documented, then modeling it might be a part of the IT 
development project. 



2.1 Typical Business Challenges 



17 



EM supports establishing a common understanding and an agreement among the 
stakeholders about such business problems and objectives. Strategy development 
will usually have to include the definition of priorities and solving conflicting 
intentions and/or implementation alternatives. EM can support this by linking 
goals and problems to the current situation and among each other. By doing this, 
it usually becomes clear what problems need to be solved with priority to reach 
certain goals and, in turn, what IT applications, infrastructure components, business 
processes, and organization units will be affected. The IT strategy as such will have 
to be documented in a suitable manner that should include the goal and problem 
models as well as the parts of the IT and the enterprise that will have to be changed 
in the future (Table 2.5). 

Enterprise Modeling activities on the tactical level translate the long-term 
strategic objectives into midterm planning steps to be implemented. Often, this is 
prepared as a road-map defining one or several packages of changes in the infor- 
mation system architecture or IT infrastructure. EM is a valuable technique for 
defining the “to be” situation and the different change packages. This can include 
defining, for example, the following: 

• Initial plans for the required change projects for IT applications and information 
systems, e.g., introduction of new systems, replacement of existing IT, forward 
development of custom-made software, integrating of enterprise applications, 
etc., 

• The necessary changes in business processes and/or new management services 
and functions to be introduced, 

• Changes in the organization structure and role distribution of the IT department. 

At this stage not only the decision makers from business areas and IT driving the 
changes and the experts from business and technical perspective should be 
involved, but the responsible roles for ah affected processes and functions. The 
aim of the modeling is to reach a common understanding and agreement about the 
future situation. The enterprise models for the future situation should be more 
detailed for the tactical planning than for the strategic planning. 

If a comprehensive model of the IT architecture exists or was developed for the 
strategic level, this has (a) to be enriched to accommodate information about planned 
changes and (b) prepared in several versions showing the planned status at different 
stages of organizational transition to the desired future state. For this kind of roadmap 
planning, specialized tools in the category of IT portfolio planning exist. 

The operational part of an IT strategy has to include very detailed short-term 
objectives and corresponding plans as well as instructions for their implementation. 
This usually is a refinement of the tactical planning and, hence, the enterprise 
models developed for the tactical stage can form the starting point for the opera- 
tional planning of the implementation. In the same way the operational objectives 
should be directly contributing to the goals defined in the strategic level. However, 
for the actual operational planning of day-to-day work the organization should use 
project management tools in combination with — depending on the planned activity — 
workflow management tools or software development tools. Tables 2.5 and 2.6 
summarize the feature of EM for business and IT alignment. 
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Table 2.5 Features of EM for IT strategy development, strategic level 



EM for developing the strategic level of an IT strategy 



Purpose 


Define the long-term objectives for the IT in an enterprise and how to 
reach them 


Input required 


Corporate strategy for the enterprise (if defined) or long-term objectives/ 
challenges of the enterprise from business perspective 


Who should be 
involved? 


IT Management of the enterprise; representative of corporate manage- 
ment; representative of different divisions or business lines in the 
enterprise 


Typical outcome 


Strategic objectives for the IT in an enterprise and how they contribute to 
corporate objectives; problems to overcome with respect to strategic 
objectives; long-term plan of IT changes to be implemented and rough 
analysis of processes and functions affected 


Critical quality 
issues 


Clearly defined realistic and controllable objectives; acceptance by 
stakeholders; long-term plan for IT changes has to show stages with 
accepted priority 


Tool support 


Traditional modeling on paper and plastics for objectives/problem 
modeling 



Table 2.6 Features of EM for IT strategy development, tactical level 



EM for developing the tactical level of an IT strategy 



Purpose 


Refine the planning and measures defined on the strategic level into 
midterm planning steps 


Input required 


Results of the strategic level of IT strategy development 


Who should be 
involved? 


Decision makers from business areas and IT driving the changes; experts 
from business and technical perspective; responsible roles for all affected 
processes and functions 


Typical outcome 


Planning of changes in IT applications and information systems; planning 
of changes in processes and functions affected; update of information 
system architecture 


Critical quality 
issues 


Clearly defined contribution to strategic objectives; feasibility of planned 
change projects in time, budget, and quality 


Tool support 


Enterprise modeling tools; enterprise architecture management tools 



2.2 How Does EM Help? 

Enterprise Modeling helps to tackle the challenges discussed in Sect. 2.1 by offering a 
flexible but systematic way of working (i.e., a method), tools of different kinds 
supporting this way of working, and experience-based recommendations for how to 
do things and how not to do things, so-called practices. This support with methods, 
tools, and practices provided by EM can be used for a variety of different tasks and 
situations due to the different perspectives of modeling, which are supported. 
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The perspectives urge the modeler to look at the enterprise from a specific angle 
and guide the modeling process in a way that specifically captures and analyzes the 
specific perspective. All perspectives are equally important because they allow 
building a holistic view on a problem situation, solutions, and the enterprise as a 
whole. For specific purposes, one perspective may be guiding the work; hence it 
might be practical to start modeling with that perspective. The different perspec- 
tives at first may seem independent and produce different models — one for each 
perspective. This is a false impression; all perspectives are mutually dependent on 
each other and modeled in an integrated way since they all reflect the same 
modeling subject, i.e., the same enterprise. 

The most important perspectives used in EM are the following: 

• The goals and problems perspective: future development and daily operations in 
enterprises should be guided by clearly defined goals, which can be set on 
general enterprise level or specifically for certain enterprise functions, business 
areas, or parts. In order to achieve the goals, problems, weakness, threats, and 
challenges have to be solved. Relationships and dependencies between goals and 
problems need to be understood. 

• The business process perspective: value creation activities, management, and 
support tasks often are conducted in business processes which have to be 
continuously improved in order to support the business goals. In many 
process-oriented enterprises, business processes, and their systematic manage- 
ment are considered the key for efficiency. 

• The organization structure perspective: the different organizational functions are 
provided by organization units forming the organizational structure of the 
enterprise. Within these units, actors and roles with defined tasks and responsi- 
bilities perform the business process. 

• The technical components perspectives: both business processes and roles are 
connected to resources used within the process or for fulfilling the responsibil- 
ities. These resources can be IT systems and applications, information resources, 
or other types of machinery. 

• The product perspective: products of enterprises can be physical products 
produced with enterprise resources or services provided by the enterprise. To 
visualize and understand the components or parts of these products or services 
can be essential for understanding the business. 

• The concept perspective: when sharing knowledge about dependencies and 
relationships between processes, roles, products, and services of an enterprise, 
it is important to use essential terms with exactly the same meaning. Thus, these 
concepts should be expressed and defined explicitly. 

• The business rule perspective: in order to achieve certain business goals or to 
control the business processes, definition of specific rules to apply often is 
inevitable. Such business rules also are related to the concept perspective. 
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2 Business Challenges: And How Enterprise Modeling Helps 



Table 2.7 Importance of the different perspectives for the business challenges 



Business challenge 


Guiding 

perspective 


Complementary perspectives 


Understand organizational 
dependencies 


Organization 

structure 


Business processes, products, business rules, 
technical components 


Find the need for change 


Goals and 
problems 


Concepts, business processes, organization 
structure, technical components 


Improve business 
processes 


Business 

processes 


Organization structure, business rules, technical 
components, concepts 


Align organizational strat- 
egy and IT 


Goals and 
problems 


Concepts, business processes, technical compo- 
nents, organization structure 


Develop the IT strategy 


Technical 

components 


Concepts, business processes, organization 
structure 



Table 2.7 illustrates which of the perspectives introduced above is of highest 
importance for the different challenges discussed in Sect. 2.1 (“guiding perspec- 
tive”) and which other perspective form important complementary perspectives. 
This makes clear that it depends on the modeling purpose which guiding perspec- 
tive has to be used. 

Tools for EM support capturing the above perspectives either only for specific 
perspectives or for an integrated view on all perspectives. Furthermore, different 
tool categories support the complete EM life cycle from early phases like scoping or 
project definition to use of models developed for process improvement or informa- 
tion system development. 

Many EM activities require a clear objective, participation of several stake- 
holders from the enterprise, an adequate resource allocation, and a thorough time 
plan. They should not be performed “on the side” of daily business, but organized 
and treated as projects. Setting up such projects has many similarities to other kinds 
of organizational change, system introduction, or development projects, but there 
also are specifics of EM which have to be taken into account. Thus, support for EM 
also has to include activities for preparing and organizing EM projects. 



2.3 For Enterprise Modeling (4EM): An Example EM 
Method 

During the long history of EM, several hundred methods have been proposed, most 
of them in a scientific context without ever reaching a level of maturity that is 
required to be used in practice. Among the established methods, only a few are 
thoroughly documented and publicly available; many are proprietary knowledge of 
consultancy firms or system integrators. All perspectives presented in Sect. 2.2 are 
represented in the most of these methods, but only some methods cover all 
perspectives. For this book, an EM method was needed which includes all perspec- 
tives, is openly available, and has a high maturity. Only introducing EM on a 
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conceptual level, i.e., without a concrete way of working, was not an option since 
this would lack sufficient practical advice. 

We decided to use the 4EM method in this book and to introduce it when 
discussing the perspectives and the way of working in Chap. 5. The 4EM method 
is rooted in both academia and practice, but it is not a commercial product. This 
book does not intend to focus on the method as such; the method is used to illustrate 
the different perspectives and a systematic way of working with EM. Hence, 4EM 
serves as a vehicle to transfer this kind of knowledge. Experience shows that it is 
easy to switch from 4EM to another method, since most concepts and perspectives 
used in 4EM are also available in other EM methods. Furthermore, in many 
industrial contexts and enterprises, certain ways of working, and specific modeling 
languages are already established, i.e., models, tools, and practices exist. In such 
cases it is important to be able to switch to the existing enterprise standards. 

4EM is presented in much detail in Chaps. 6, 8, and 9. More information about 
the origin of 4EM can be found in Sect. 7.5. 



Chapter 3 

Terms and Concepts in Enterprise Modeling 



In Computer Science and Information Systems, models play an important role for 
different purposes. This chapter will start by defining and explaining general terms 
used in the context of modeling. The concept of model is introduced in Sect. 3.1. 
The term “method” and the constituents of methods are discussed in Sect. 3.2 
before investigating the term Enterprise Modeling and Enterprise Modeling method 
and then presenting the components of enterprise models and ways to represent 
such models in Sect. 3.3. 



3.1 What Are Models and Why to Use Them? 



Changes and improvements in enterprises usually have to be based on understand- 
ing the existing situation, i.e., the reality in the enterprise under consideration. This 
reality is complex and can be analyzed from different perspectives, but not all 
perspectives and not all aspects of reality are required and relevant for solving the 
problem or completing the task at hand. Modeling generally aims at capturing only 
the relevant aspects of reality in a representation, called the “model,” which can 
then be used for the intended purposes, such as analysis and development. 

Not only are models extremely important in Computer Science and business 
information systems, but they also have a wide variety of uses in other fields and 
even in everyday life. A street map, for example, is a model that reflects the reality 
of a particular town. Depending on its purpose, the emphasis could be on highly 
detailed information for road users, or it might instead show the cultural and 
recreational activities available. In architecture, three-dimensional models may 
for instance be used to show the design of a building, while other models, such as 
architectural drawings, are used for planning floor layouts. In chemistry, balls and 
sticks are used to create models of molecules. In mathematics, models are used to 
accurately describe and gain a better understanding of technical or natural systems. 
The terms “model” and “modeling” are defined more precisely below. 
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3 Terms and Concepts in Enterprise Modeling 



3.1.1 Model 



A model is a generalized representation of a piece of reality, with only 
relevant real-world properties taken into account during modeling. 



A model is traditionally defined as a generalized representation of reality or a piece 
of reality, with only relevant real-world properties taken into account during 
modeling (Kiihne 2006). Stachowiak (1973) describes the three main characteris- 
tics of a general model as follows: 

• Mapping: models are always mappings (representations) of real or abstract 
originals, which may, in turn, be models themselves. 

• Reduction: models contain only those attributes of the corresponding original 
which are relevant to the modeler and the intended model user. 

• Pragmatism: models are not inherently assigned to a specific original. They are 
utilized by a model-using subject within a particular time frame “and within the 
constraints of certain conceptual or actual operations.” 

When abstracting (reducing the level of detail) and mapping a reality in a model, 
it is important to maintain similarity between the model and the part of reality that 
was modeled. Here we can distinguish between: 

• Structural similarity: the structures represented in the model are retained from 
reality. When representing an enterprise’s organizational structures or product 
structure, for example, the model should reproduce these structures correctly and 
as fully as possible. 

• Functional similarity: often, reality can be broken down into components or 
parts based on the tasks which they perform. A model that is intended to 
represent this functional perspective must accordingly reflect the components 
and functions of reality. 

• Behavioral similarity: if the model is intended to express a behaviour observed 
in reality, for example, over a particular period of time when events occur, or 
under particular conditions, similarity between the model and reality must be 
achieved in this respect. 

Among other things, enterprise models are used to describe or capture the 
“current state” — that is, the current situation or relationships in enterprises or 
divisions. In doing so, the abovementioned similarity requirements must always 
be met in order to achieve the most accurate and understandable representations 
possible. If models describe a desired future situation, i.e., what is known as the 
“target state,” they can be used to guide and assist those involved in the change 
process. 

A model of the “current state” will rarely be an exact replica of the real world. 
This is due to the modeling characteristics described above — i.e., mapping, reduc- 
tion and pragmatism, as well as the subjective perception of those that contributed 
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to the model creation. Thus a model is also characterized by a collective perception 
of the real world that reflects the contributors’ frames of reference, experiences, and 
backgrounds. 

3.1.2 Modeling 

The process of creating and constructing models is called modeling. Bubenko 
(1992) defines modeling as follows: 



“Modeling means essentially to describe a set of abstract or concrete phe- 
nomena in a structured and , eventually , in a formal way. Describing , model- 
ing and drawing is a key technique to support human understanding, 
reasoning and communication.” 



Modeling generally results in models. In order to obtain models with relevant 
content and the desired properties, modelers use a formal model derivation and 
analysis process (Bubenko 1992), which can often be referred to as a method (see 
Sect. 3.2). The following aspects should be considered when modeling, regardless 
of the specific method: 

(a) Defining the problem and the purpose of the model: the task, and therefore the 
problem to be solved, must be clearly defined and should form the basis for 
defining the purpose of the model. 

(b) Delimiting the problem: it is essential to define what is part of the model or 
problem and what is not. When developing medium or long-term enterprise 
strategy, for example, detailed planning may potentially be left out. 

(c) Identifying important model objects: for example, when modeling an overall 
structure of an organization the model should only record important objects, 
such as departments, roles, and locations, and how they interrelate. 

(d) Acceptability and users: a model should be tailored to the model users as well as 
to the problem and purpose. Issues may arise if, for example, the modeler does 
not know the necessary relationships and designs models that are not accepted 
by the model users. 



3.1.3 Modeling Language 



The outcome of the modeling process is documented using modeling lan- 
guages, which can be classified as textual and visual languages. In Enterprise 
Modeling, visual languages with diagrammatic representations are common. 
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3 Terms and Concepts in Enterprise Modeling 



In Computer Science and business information systems, the product of the 
modeling process — i.e., the developed models — are documented using modeling 
languages. A distinction can be made between textual and visual (or graphic) 
modeling languages based on the representation format that they use. Like pro- 
gramming languages, textual modeling languages are defined by a grammar. By 
contrast, visual modeling languages normally use diagrams to represent the model. 
In these diagrams, geometric shapes (rectangles, circles, ellipses, etc.) connected by 
lines and arrows are used as graphic symbols. Often, details of how these symbols 
and connections should be labeled are also specified. Most Enterprise Modeling 
languages are visual languages. The language for the 4EM method presented in 
Chapter 8 is a concrete example of this. Visual languages are also used in infor- 
mation technology for other purposes, such as in information modeling using entity 
relationship diagrams or in software development with UML as the modeling 
language. 

In a modeling language, the underlying abstract syntax defines how the symbols 
can be used and interconnected. In addition to syntax, modeling languages also 
have semantics, although a distinction must be made between formal and informal 
modeling languages. Formal modeling languages have precisely defined semantics, 
known as operational semantics. In informal modeling languages, however, the 
semantics is only colloquially defined or indirectly provided through an established 
practical application. The advantage to formal modeling languages is that syntactic 
and semantic errors can be detected with tool-based checking algorithms, or even 
prevented during modeling. This allows these models to be transformed into other 
modeling languages more easily and often without a loss of semantics, which would 
for example allow enterprise models to be used in the software development 
process. 



3.2 What Is a Method? 



A method describes the approach to Enterprise Modeling by formulating a 
set of underlying principles as well as detailed and systematic work 
procedures. 



Methods are used to concretely define the modeling approach. However, the term 
“method” does not have a standard definition in business information systems 
literature and textbooks. A method, in the most general sense, is used to describe 
problem solution approaches. These approaches give rise to detailed and systematic 
procedures that describe how and according to what principles a specified goal can 
be achieved. 




3.2 What Is a Method? 



27 



Conceptualisations of methods 




Fig. 3.1 Method components according to Goldkuhl et al. (1998) 



The term “method” can be refined for the purposes of Enterprise Modeling. This 
book will do so, based on the work of Goldkuhl et al. (1998). In their definition, 
Goldkuhl et al. state that a method provides instructions for working, i.e., a method 
provides a guideline with steps that must be executed in order to achieve 
predetermined goals in various situations. A comprehensive method description 
should describe the perspective, framework, cooperation principles, and all method 
components. Figure 3.1 illustrates how these method components are related, and 
all parts are explained briefly below. 

Method components: concrete instructions for the modeler can be found in the 
method components, of which a method must contain at least one. A method 
component should consist of concepts, a procedure, and a notation. The concepts 
specify what aspects of reality are regarded as relevant in the modeling process, i.e., 
what is important and what the modeler must look out for in order to capture it in a 
model. These relevant concepts should be named in the method component and 
explained if necessary. In a method component for process modeling, for example, 
processes, external processes, and information sets will be relevant. These concepts 
and their differences should be explained in the method component. The procedure 
describes in concrete terms how to identify the relevant concepts in a method 
component and represent these in a model. It may also cover prerequisites and 
resources. The notation specifies how the result of the procedure should be 
documented. As a rule, this must provide appropriate expressions for each concept 
and for the potential relationships between them. In graphic notations, these are the 
symbols to be used. 
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3 Terms and Concepts in Enterprise Modeling 



Framework: the method framework describes the relationships between the 
individual method components, i.e., which components are to be used and under 
what conditions, as well as how and with which subsequent component or compo- 
nents the results are to be used. In a lot of methods, the sequence of the method 
components is always the same, which is why the framework is not described 
separately, but implicitly provided by the description of the method components. 

Forms of cooperation: many modeling tasks require a range of specialist skills or 
cooperation between different roles. These necessary skills and roles must be 
described, along with the division of responsibilities between the roles and the 
form of cooperation. The cooperation form also includes who will take responsi- 
bility for each task or method component, and how the collaboration will be 
organized. Two main role categories can often be distinguished: method experts 
and stakeholders knowledgeable in the facts to be modeled. 

Perspective: every method describes the procedure for the modeling process 
from a particular perspective, which influences what is considered important when 
representing reality in a model. One Enterprise Modeling method, for example, 
might make the perspective of business goals and intensions its focus, while another 
Enterprise Modeling method works from the perspective of processes and struc- 
tures. Many existing methods do not explicitly describe what perspective is used, 
but it is implicitly clear from the framework or method components. If the perspec- 
tive is explicitly described, it contains the values, principles, and categories under- 
lying the method and in essence delimiting what aspects of the problem domain 
should be modeled. This means that a perspective forms the conceptual and value 
basis of the method. 



3.3 What Is Enterprise Modeling? 



The start of this Sect. 3.3.1 briefly introduces various definitions of the term to raise 
awareness of different views on Enterprise Modeling found in the literature on the 
subject. Afterwards, the fundamental types of representation that can be used for the 
models produced by Enterprise Modeling (Sect. 3.3.2) and the elements that make 
up an enterprise model (Sect. 3.3.3) are described. 



3.3.1 Definitions of the Term “Enterprise Modeling” 

A variety of definitions regarding the discipline of Enterprise Modeling can be 
found in the literature. The lack of a standard, generally accepted definition is due to 
differing viewpoints as to how formal enterprise models should be and for what 
purposes they can be used. This can be illustrated by two examples from knowledge 
representation in computer science and industrial organization. 
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The following definition, proposed by Vernadat in 2002, has its roots in indus- 
trial organization and the field of enterprise engineering: 

“Enterprise modeling is the art of externalizing knowledge which adds value to the 
enterprise or needs to be shared. It consists of making models of the structure, behavior 
and organization of the enterprise.” (Vernadat 2002) 

Vernadat advocates an industrial approach, in that he regards an enterprise as 
being similar to a product and thus divides it into modules and components, just as 
more complex products are handled. The models that are produced in Enterprise 
Modeling display the externalized knowledge structure of an enterprise, but are 
usually only a snapshot and are therefore only valid for a short time. The partici- 
pants in an Enterprise Modeling activity should be able to use these models to plan 
the enterprise’s future situation or to allow new processes or structures to be 
designed, e.g., using sub-models for this purpose. They are essentially intended 
for use by the managers and employees in the enterprise. In other words, processing 
or execution by computer is not a priority. 

In contrast to Fox and Gruninger (1998) advocate a different view of what 
Enterprise Modeling is: 

“An enterprise model is a computational representation of the structure, activities, pro- 
cesses, information, resources, people, behavior, goals and constraints of a business, 
government, or other enterprise. It can be both descriptive and definitional — spanning 
what is and what should be. The role of an enterprise model is to achieve model-driven 
enterprise design, analysis and operation.” (Fox and Gruninger 1998) 

In this approach to creating enterprise models, complete formal definitions of the 
information contained in each perspective are produced in the form of rule sets. 
These are very well suited to computer-based enterprise model representation. The 
major benefit to this approach is that the enterprise model is formally described with 
a focus on executability and completeness, and thus allows already modeled 
components to be reused. For this reason, such enterprise models are used more 
in the context of knowledge representation and artificial intelligence, as the high 
degree of formalization is not entirely suitable for communication with executives 
or other decision makers. 

The understanding of Enterprise Modeling in this book is based on the definition 
given in (Bubenko et al. 2001) as follows: 



Enterprise Modeling (EM) is the process of creating an integrated enterprise 
model which captures the aspects of the enterprise required for the modeling 
purpose at hand. An enterprise in this context can be a private company, 
government department, academic institution, other kind of organization, or 
part thereof. An enterprise model consists of a number of related sub-models, 
each focusing on a particular aspect of the enterprise, e.g., processes, business 
rules, concepts/information, vision/goals, and actors. An enterprise model 
describes the current or future state of an enterprise and contains the com- 
monly shared enterprise knowledge of the stakeholders involved in the 
modeling process. 
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3 Terms and Concepts in Enterprise Modeling 



The emphasis in this book is on enterprise models to help managers and other 
stakeholders in the enterprise to further develop the enterprise and/or solve existing 
problems. Formalization in the sense of using a modeling language to represent the 
model is a part of the 4EM approach, but executability or the ability to transform 
models into other notations is not the primary concern. 



3.3.2 Enterprise Model Representations 

Enterprise models can generally be presented in a variety of ways. Allweyer (2010) 
proposed a classification of these, which is explained in this section. This classifi- 
cation distinguishes four types of description technique for models, according to 
(Allweyer 2010): 

(a) Textual description 

(b) Tabular representation 

(c) Graphic representation without the use of a specific notation 

(d) Graphic models with of a defined notation 

Structured text descriptions using natural language are the simplest means of 
documentation, and also highly flexible as there are no restrictions as to what 
terminology and formulations may be used. However, complex facts quickly 
become confusing with this approach, and the individuality of description shows 
the greatest variation between authors. Furthermore, neither automated processing 
nor analysis of the descriptions is possible. Figure 3.2 shows an example in which 
only a structure divided into goals, business processes, and stakeholders is 
predefined. In practice, this type of textual representation is used in Enterprise 
Modeling: 

• To create a very rough overview of the most important processes and structures 
in the enterprise before starting the actual modeling process, such as when 
defining the limits of the modeling project, or 

• When enterprise models have reached a level of detail where further refinement 
using semiformal or formal modeling languages is no longer practical, and the 
tasks, duties, or functions can be better described in a textual format. 

Tabular representations, the second form of structured description, are also easy 
to create and understand. Furthermore, this representation provides basic options 
for comparing and analyzing tables. When tabular representations are highly 
formalized and use particular predetermined terms, for example, it is possible for 
the information they contain to be processed automatically. However, there also are 
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Goals: 

The managenent has defined the overall goal of reaching an increase in revenues of 
15% during this year. Furthermore, reduction of costs of operations by 10% is 
considered another important goal for the enterprise. Several proposals were 
considered to reach this objective. One option would be to invest in more efficient 
production machinery, but the required investments are financially not affordable for 
the enterprise. Thus another option was selected: to avoid or reduce costs of repairs 
byimproved maintenance. [...] 

Business Processes: 

Two sales persons are working in the shop. Their main task is to take care of the 
customers and support them by giving advice in selecting the right products. After 
selecting a product, the customer has the option to choose the standard version of the 
product or to add engravings. In case the standard product is selected, the payment 
process is initiated; the products are taken from the shop-internal stock and handed 
over to the customer. [...] 

Organization Structure: 

The enterprise has four departments: marketing, shop, IT and production. Each of 
these departments has two employees with dedicated tasks. Example: In the shop are 
two employees who take care of the sales process. [...] 



Fig. 3.2 Example for the textual description of an enterprise model part 

problems with using tabular representations to describe complex facts, as in the 
case of multi-nested structures or iterations on different levels. Tables can be 
created with office tools, and are generally clearer than purely textual description 
formats. Table 3.1 shows an example of a tabular representation. Similarly to 
textual descriptions, tabular representations can be used in the early phases of 
modeling to create initial overviews or to supplement detailed refinements. 

The third option is graphic representation without the use of a formal notation. 
Here, models are represented using graphic elements, and how they are arranged or 
connected is meant to convey certain semantic meaning. These descriptions are 
easy to create and are a good documentation method for creative modeling work- 
shops in particular. The high level of clarity can be further improved with the help 
of graphics applications such as mind map programs, but the inconsistent repre- 
sentation and the depiction of complex facts are again problematic, for example, 
when comparing and evaluating the descriptions. Figure 3.3 shows an example of a 
graphic representation without formal notation. Arrows and rectangles in this figure 
have no formal meaning and are used to represent both activities (e.g., “maintaining 
online presence”) and stakeholders (e.g., “customer”). Hence, such drawings are 
difficult to use in a broader audience because those that were not part of the initial 
modeling activity might interpret it differently. Graphic representations of this kind 
can be created with drawing tools, as described in Sect. 5.2.1. This way of informal 
documentation of models is not recommended because it leaves room for misinter- 
pretation. In addition, stakeholders might get used to modeling without even a 
minimal set of rules, which might later cause problems when a more formal 
modeling method is used. 
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3 Terms and Concepts in Enterprise Modeling 



Table 3.1 Example of the tabular representation of an enterprise model part 



Goals 


1. Increase revenue by 15 % in the cur- 
rent year 




2. Increase sales by innovation 


2.1 Develop new product variants 


measures 


2.2 Shorten time to market 




2.3 Improve service offers 


3. Reduce operative costs by 10 % 


3.1 Reduce repair costs for machinery 




3.2 Establish long-term contract with logistics service 
providers 


4. Optimize production 


4. 1 Reduce production time 



Business Processes 



1. Maintenance of website 


1.1 Keep E-Shop up to date 


1.2 Insert new content 


1.3 Remove errors on website 


2. Product catalog search 




3. Online orders 





13. Produce standard product 



13.1 Check quality of supplies 




Fig. 3.3 Example of a graphical representation without use of a formal notation 



The fourth representation type is graphic representation with a more formal 
notation. This representation format uses a predetermined language and notation to 
structure facts. The language may contain both graphic and textual elements. 
Formal definition of the language and notation has a number of advantages that 
particularly come into play in extensive modeling projects and when modeling 
complex facts: 



3.3 
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(a) Models can be used for communication among stakeholders and developers 

(b) The models can be checked to ensure that the language and notation are correct, 
which helps to avoid errors in the models. 

(c) Computer-aided comparison of different models is possible, e.g., between 
models of the current situation and the target situation, or between different 
enterprises or divisions. 

(d) The information contained in the model can be reused, for instance, in com- 
puter-based information systems and to develop software solutions. 

(e) Depending on the model purpose as well as the language and notation, it is also 
possible to simulate the sequences recorded in the model or to manage 
workflows. 

Furthermore, avoiding the use of natural language helps minimizing ambiguity, 
which in turn reduces misunderstandings caused by varying perceptions and con- 
ceptual and cultural differences, which often occur when people communicate. 

Figure 3.4 shows an example of a graphic representation with formal notation. In 
this case, the notation corresponds to the 4EM method presented in this book. In 
principle, simple drawing tools (Sect. 5.2.1) can be used to create descriptions of 
this type; however, it is more beneficial to use modeling environments (Sect. 5.2.2) 
that provide support specifically for the language and notation used. The best way 
of uniformly representing and evaluating more complex facts is using graphic 
representations with formal notation. A disadvantage to this is that everyone 
involved in the modeling process must be taught the selected language and how 
to interpret it. From an EM perspective, we recommend simple and easy to learn 
notations. As we will discuss this in Chap. 9, during a modeling session it is the 
responsibility of the modeling facilitator to make sure the notation of the method is 
followed. This reduces the need to train the modeling participants in modeling 
before the workshop and they can leam from their hands-on experience. 




Fig. 3.4 Example of a graphical representation using a more formal notation 
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3.3.3 Components of Enterprise Models 



The terms “model” and “modeling language” have already been covered in 
Sect. 3.1. To describe a visual modeling language in the context of an Enterprise 
Modeling method, as is the case in Chap. 8 of this book, terms for the parts that 
make up such visual models must also be introduced. A visual model consists of 
symbols, mostly in the form of geometric shapes such as rectangles and ellipses, 
and the lines connecting them, such as arrows. The symbols are referred to as model 
components (or components, for short), and the connections as relationships. 
Together, model components and relationships are known as model elements. 

These are distinguished by model component or relationship type, depending on 
the types provided in the modeling language that is used. Every model component 
thus has a specific type — the model component type (or component type, for 
short) — and every relationship has a specific relationship type. Together, model 
component types and relationship types are referred to as elements of the modeling 
language. The component types that can be connected with which relationship type 
must be defined. In modeling languages, this is done with rules and integrity or 
consistency conditions. 

The terms “model component,” “component type,” “relationship,” and “rela- 
tionship type” mentioned earlier will be described in more detail below. 

Model Component Type (Component Type) 

• A (model) component type identifies a set of model components of the same type 
or sort. 

• In visual modeling languages, a component type is represented in a predefined 
way, often by a specific graphical symbol. The symbol is commonly a geometric 
shape in a certain color and, if applicable, with a specific line type. 

• Each component type has a predefined set of attributes to record information 
about the model components belonging to the component type. In the simplest 
case, there is only one attribute: the name of the respective model component. 

• The component types that may be used are defined in the modeling language. 

Examples of component types commonly used in Enterprise Modeling are goal, 
process, role, organizational unit, resource, and IT system. 

Model Component 

• In an enterprise model, each model component represents an element of the 
reality in the modeled enterprise. 

• Each model component has a specific type, and uses the representation and 
attributes defined by the component type. 

Examples of model components might be “collect customer data” for the 
component type “process,” or “purchasing department” for the component type 
“organizational unit.” 
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Relationship Type 

• A relationship type identifies a set of relationships or connections of the 
same type. 

• The component type(s) from and to which the relationships may lead is defined 
for every relationship type. 

• In visual modeling languages, a relationship type is represented by a predefined 
graphic element. This element is commonly a line of a particular type (solid, 
dashed, dotted, etc.) in a certain color and, if applicable, with predefined line caps. 

• Each relationship type may have a predefined set of attributes to record infor- 
mation about the relationships belonging to the relationship type. The individual 
relationships in a model generally take the name of the relationship type. Unlike 
model components, they are not given an individual name. 

• The relationship types that may be used are defined in the modeling language. 

Examples of relationship types frequently used in Enterprise Modeling are 
“responsible_for” as the relationship between a role and process, or “supports” as 
the relationship between two business goals. 

Relationship 

• In an enterprise model, each relationship represents a connection between two 
elements of the modeled enterprise’s reality, which are represented as model 
components. 

• Each relationship has a specific type and uses the representation and attributes 
defined by the relationship type. 

An example of a relationship might be that the model components “purchasing 
department” and “collect customer data” are linked by the relationship 
“responsible_for,” i.e., the purchasing department is responsible for collecting 
customer data. 



3.3.3.1 Views and Levels 

Enterprise models for extensive modeling projects or complex processes may 
consist of a large number of model elements, making them unclear or difficult to 
display. To allow the complexity of the representation to be reduced, many model- 
ing languages support views and levels. 

Views do not change the actual enterprise model, but rather define what parts of 
the model are displayed at particular time. A view contains only those model 
elements that have been specified for inclusion in the view definition. The compo- 
nent types and relationship types that the view should contain generally define a 
view. If for example the “process view” for an enterprise model contains only the 
model’s processes and their relationships, the roles responsible for them, and the IT 
systems used, then the component types “process,” “role,” and “IT system” and the 
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Table 3.2 View concepts of different modeling approaches 



Modeling 

approach 


Views 


Recommended 

literature 


ARIS 


Organization, function, data, control, service view 


Scheer and 
Niittgens (2000) 


According to 
Weske 


Function, information, organization, IT 


Weske (2012) 


PICTURE 


Organization, business object, process, resource 


Becker 
et al. (2007) 


4EM 


Goal/problem, business process, business rules, actors and 
resources, technical components, concept 


Sect. 8.2 



relationship types allocated to “process” are a part of this view, but other model 
component types or relationship types are not. 

The specific views available are predetermined in most modeling languages or 
methods. The Table 3.2 shows a few examples and that the number of defined views 
can vary significantly, and that although certain views are common, the naming for 
these views can differ, e.g., the process, workflow, or business process view 
(see Table 3.2). 

Working with views is to large extent determined by functionality of the 
modeling tool. For example, some tools support user-defined views based on 
queries, such as show all processes that the purchasing department is 
responsible for. 

Levels are used to allow model components to be refined. This means that if the 
parts or decomposition structure of a model component need to be refined for 
modeling purposes, the model component can be refined elsewhere in the enterprise 
model, on the subjacent refinement level. The existence of a refinement is generally 
recognizable from the representation of the model component in the upper level, 
such as the symbol labeling. The model component and refinement are clearly 
associated with each other, for example, by an identifier. All relationships to the 
model component in the upper level must also exist in the refinement level and be 
clearly related to the model components in the refinement level. Refinements of 
model components are often presented as sub-models. 



3.3.3.2 Stakeholders and Modeling Activities 

An Enterprise Modeling project usually consists of numerous steps including 
modeling activities. By modeling activities we mean all activities involved in 
constructing or developing models, such as moderated modeling sessions, work- 
shops, creating models based on data by analysis activities (interviews, document 
analysis, etc.). There are many different actors involved in the modeling process. 
All those that have direct or indirect interest in modeling or the results are regarded 
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as stakeholders. Stakeholders also are those that have no decision-making role in 
the course of a modeling activity or who do not have relevant information, but may 
still contribute to the project result, for example, with experience in similar projects. 
Stakeholders can be divided into two main groups: internal and external stake- 
holders. External stakeholders include customers, partners, subcontractors, legisla- 
tors, and shareholders of the enterprise. The employees, project team, the 
departments concerned, managers, and executives are part of the internal stake- 
holder group. 

Stakeholder relation to a project or its outcome is not always overt. There can 
also be so-called indirect or hidden stakeholders. They may, for instance, be 
members of the management hierarchy with some interest in the project outcome 
and who could be positively or negatively affected by it. The critical factor for the 
success of Enterprise Modeling and the resulting change initiatives is to involve all 
relevant stakeholders in the project. Identifying relevant stakeholder groups is a key 
activity during the preparatory stages of modeling discussed in more detail in 
Chap. 9. 

3.3.4 Enterprise Modeling Method 

The term modeling method and modeling language is sometimes in practice used as 
synonyms, which can be confusing. Furthermore, the modeling language itself is 
not enough to achieve the goals of Enterprise Modeling. The user of a modeling 
language needs guidance for how to use the modeling language in a practical 
context. 

In this book the term Enterprise Modeling method has a specific meaning in that 
it has two components (Fig. 3.5): 

1. The Enterprise Modeling language, with a defined syntax, semantics, and nota- 
tion, i.e., the building blocks of an enterprise model. The language of the 4EM 
method is described in Chap. 8. 

2. The Enterprise Modeling process, with a set of recommended elicitation 
approaches (Chap. 4), a set of tools (Chap. 5), and a project approach (Chap. 9). 
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Elicitation approaches 

• Interviews 

• Observation 

• Document analysis 

• Self recording 

• Participatory 
modeling workshop 



Tools 

• Computer 
based tools 

• Other tools 



EM language 

The building blocks and rules 
used to construct enterprise 
models 



EM process 

How an EM language is 
used to construct 
enterprise models 



Fig. 3.5 Components of an Enterprise Modeling method 



Chapter 4 

Elicitation Approaches in Enterprise 
Modeling 



One of the key tasks in Enterprise Modeling is to analyze the current situation and 
existing challenges in the enterprise with the active participation of domain experts 
and decision makers. In this respect, elicitation approaches such as interviews, 
observations, participatory modeling workshops, or document analysis are funda- 
mental instruments. 

Starting with an overview of the most important elicitation approaches in 
Enterprise Modeling (Sect. 4.1) and some advice on preparing for elicitation 
(Sect. 4.2), the chapter introduces selected elicitation approaches (Sect. 4.3) and 
in particular participatory modeling workshops, which is the main recommended 
approach in most cases, particularly in the 4EM method (Chap. 8), although it 
should be complemented with preparatory interviews. The chapter introduces the 
basic principles of these approaches and provides resources such as guidelines and 
checklists for practical use. 

4.1 Overview of Elicitation Approaches 



Enterprise models represent the situation within the enterprise in question, 
both in terms of the current state and the future state of affairs. This is only 
possible if the modeler is able to correctly and fully obtain! elicit relevant 
knowledge from within the enterprise. Elicitation approaches are essential 
for this purpose. 



One of the key tasks in Enterprise Modeling is to identify and gather knowledge 
relevant to the purpose of EM from within the enterprise. To obtain the most accurate 
view of the situation, current or future, a variety of elicitation approaches can be used. 
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One important aspect to be considered in the context of knowledge elicitation is 
whether or not the models created through EM capture the one and only truth about 
the problem at hand. We claim that they do not. They can only capture the version 
of the truth that is the negotiated view of the individual stakeholders involved. 

Why is this important to keep in mind? Because this will, among other things, 
prevent the modeling expert or modeling practitioner from framing the problem too 
narrowly or from stopping analysis too soon. Moreover, it helps her/him to realize 
that more than one person needs to represent a certain stakeholder perspective in the 
analysis since there can be different opinions about the current and future situation 
among individuals in a stakeholder group. 

Elicitation approaches make it possible to obtain knowledge from different stake- 
holders about the aspects and parts of an enterprise’s situation important for the given 
modeling purposes. Enterprise employees from various stakeholder groups are often 
the most important sources of knowledge. The term “stakeholders” generally encap- 
sulates all groups of individuals, both internal and external to the organization, who 
are involved in its current activities or who affect or will be directly or indirectly 
affected by future changes. The approaches covered in this chapter are interviews, 
observations, document analysis, work diary, and participatory modeling workshops. 

Table 4.1 summarizes, for the most important elicitation approaches, the appro- 
priate situations in Enterprise Modeling where they can be used. It also shows 
where in this book each approach is covered. 



Table 4.1 Overview of elicitation approaches in Enterprise Modeling 



Elicitation approach 


Discussed 
in section 


Appropriate situation in enterprise modeling 


Interview 


4.3.1 


The most important approach when preparing for a par- 
ticipatory modeling workshop 

Used as an alternative to participatory modeling work- 
shops when the organizational culture or situation does not 
allow for open discussions in a group setting 


Observation 


4.3.2 


When more detailed analysis of physically observable 
current situation is needed and participatory modeling 
workshops and/or interviews reveal no clear or complete 
view or result in contradictory information 


Document analysis 


4.3.3 


Preparation of the EM project or as a first step in modeling 
in order to create a model skeleton 


Work diary 


4.3.4 


Capturing more precise information about durations of 
tasks, volumes or amount of resources, or other quantita- 
tive information; often used as complement to other elic- 
itation approaches 


Participatory 
modeling workshop 


4.3.5 


Facilitated modeling with a group of stakeholders of cur- 
rent and future situation, if participation is crucial for 
quality, implementability, and acceptance of models 
Particularly useful 

• When an agreement and a joint view of all stakeholders 
is important 

• If problems and solutions can only be completely 
covered and understood if all stakeholders participate in 
the discussion or development 



4.2 Preparing for Elicitation Activities 



41 



4.2 Preparing for Elicitation Activities 



Before starting elicitation activities, the purpose of the activities should be 
defined, the necessary resources secured, the affected stakeholders informed, 
and their participation ensured. 



All forms of elicitation activities should be carefully prepared. They tie up 
resources and cost money. Good preparation helps to achieve the goals of this 
“investment” and to increase the efficiency and effectiveness of Enterprise 
Modeling. 

Before starting any elicitation activity, its purpose and scope should be precisely 
defined and agreed between those performing the analysis and those in the organi- 
zation who commissioned it. The aspects and concepts that are important must be 
derived from the purpose of the activity. 

The scope makes it possible to delimit which parts of the enterprise should be 
included and which should not. The purpose and scope together form the basis for 
planning the activities to be carried out, determining the specialists and employees 
to be involved, and estimating the cost. 

In addition, it is important to ensure that the knowledge elicitation activities are 
approved and supported by enterprise managers — not only the executives that 
commissioned the overall project, but also the managers of the subordinate orga- 
nizational units in which enterprise knowledge will be gathered. It is important to 
ensure that the employees or specialists concerned are allowed time to participate in 
interviews or workshops, that the necessary information or documents are made 
available, and that access to the appropriate organizational units and employees is 
secured for observations. 

In addition to managers, the employees involved in or are affected by the 
knowledge elicitation should be involved at an early stage. Comprehensive infor- 
mation about planned activities should be provided to ensure that attitudes towards 
them are as supportive as possible, and to avoid, if at all possible, hostile attitudes. 
The significance of the overall project to the enterprise, the purpose of the activities, 
the intended schedule, which activities are planned and who will be involved or 
affected by them, how and in what context the collected information is to be used — 
all of this should be announced before the start of the activities. The key objective 
here is to ensure that the stakeholders and persons affected have an open attitude 
towards the activities to be carried out, because this will positively impact the 
quality and relevance of the knowledge gathered. 

The following checklist summarizes the most important points in preparing for 
knowledge elicitation activities. More detail about preparing for participatory 
modeling workshops is provided in Chap. 9. 
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1. Define (as precisely as possible) and agree on the purpose and scope of the 
investigation between those performing it and those who commissioned it. 

2. Obtain approval and support from the relevant managers in the enterprise. 

• Involve all affected organizational units and don’t forget to involve external 
stakeholders if needed. 

• Agree sufficient time and resources. 

• Obtain access to existing relevant documentation. 

3. Involve those affected within the enterprise at an early stage 

• Provide information about the purpose of the activities. 

• Announce the schedule and which activities are planned. 

• Communicate who will be involved or affected and why. 

• Provide information regarding how and in what context the collected infor- 
mation will be used. 



4.3 Selected Elicitation Approaches in More Detail 



An overview of the most important knowledge elicitation approaches has already 
been provided in Sect. 4.1. This section supplements the overview by describing 
selected approaches in more detail. 



4.3.1 Interviews 



Interviews are used to systematically gather informationfor a defined inves- 
tigative purpose. Individuals or a group of individuals are asked a series of 
purposeful questions so that the answers can be documented and evaluated. 



In Enterprise Modeling, interviews are among the most commonly used approaches 
to gathering knowledge about the enterprise, for example, particular procedures, 
organizational structures, products, and resources. The various interview formats 
are summarized in Table 4.2 and explained in the rest of this section. The following 
elicitation approaches are discussed: face-to-face interviews, telephone interviews, 
group interviews, written surveys, and computer-based survey processes. 

In face-to-face and telephone interviews, the interviewer can provide assistance 
by clarifying questions and answer options. Interviews are relatively quick to 
conduct, even though they require some preparation, and the interviewer can decide 
during the interview whether and when to follow-up a point in more detail. This is 
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Table 4.2 Interview types, according to (Frankfort-Nachmias and Nachmias 2007) 





Interview format 


Medium 


Written surveys 
on paper 


Written: computer, 
e-mail, Internet 


Oral; face- 
to-face 


Face-to-face, 

phone 


Definition of 
questions 


Structured 

interview 


Semi- structured interview 


Open 

interview 


Definition of 
answers 


Predefined answers (multiple choice) 


Free-form answers 


Participants 


Single participant 


Group 



an advantage over written surveys as it allows a closer examination of individual 
answers to obtain a more comprehensive view of the interviewee’s previous 
response. An interview that is conducted with the support of an interview guide is 
called a semi-structured interview. The characteristic feature of semi- structured 
interviews is that the interview is based on a guide containing open questions that 
the interviewee can answer freely. The guide merely helps the interviewer not to 
overlook significant aspects. Structured interviews have a defined set of questions, 
which the interviewer is supposed to follow rigorously. The advantage of a struc- 
tured interview is that it provides comparable data. Comparability is achieved by 
the ability to record information directly during the conversation, which ensures 
that it is not distorted and can be understood by parties who were not involved in the 
interview. 

A group interview is a particular form of interview where several participants are 
asked about a subject. It often takes place in the form of a conversation and is led by 
an interviewer or moderator. Group interviews make it possible to gather individual 
opinions, which are expressed more spontaneously and with less control through 
discussion with the other participants. This allows contrary viewpoints to be 
identified, which may then need to be examined or investigated in individual 
interviews. 

With written and computer-based surveys, addressees fill out a questionnaire 
which may be accompanied by explanations and contain instructions on the order of 
completion. It should be kept in mind, however, that there is no guarantee that the 
addressee will fill out the questionnaire by themselves or alone, or that they will 
follow the instructions and order of the questionnaire. In principle, questionnaires 
of this kind may contain multiple-choice questions with preset answer options as 
well as open-ended questions. However, multiple-choice questions are uncommon 
when written surveys are used to investigate the current situation in the enterprise. 
Graphics and diagrams can also be incorporated in addition to the questions in order 
to better articulate the problem. One benefit to a written questionnaire is that the 
interviewee has more time to answer, which can have a very positive effect on the 
quality of the answers. They also allow a large number of individuals to be reached, 
as the surveys can be distributed through a wide variety of channels such as via 
Internet portals, by post. 
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Selecting the interview as the main approach to elicit knowledge to be incorpo- 
rated in enterprise models may seem to be the easiest choice at first. However, there 
are good arguments that the main approach should be participatory modeling 
workshops, complemented by preparatory interviews. This point of view is further 
discussed in Sect. 4.3.5. 



4.3.2 Observations 



Observation is used to systematically record and document the behavior of 
individuals or small groups and the procedures in organizational units in the 
normal operational context. 



Observation makes it possible to collect data and analyze procedures that may be 
otherwise difficult or impossible to identify. This might concern unconscious, 
incidental, or routine behavior that is difficult to investigate through other 
approaches. An important aspect of observation is that the procedures and behavior 
of interest are studied in the normal operational context, i.e., during normal working 
hours on an ordinary day at the enterprise. Frankfort-Nachmias and Nachmias 
(2007) have set out the following points that must apply to every observation: 

• The observation must serve a clear purpose (in this case, analysis of an 

enterprise). 

• The start, course, and end must be planned, i.e., not left to chance. 

• The results of the observation must be systematically recorded according to 

predetermined criteria. 

Observation can be utilized in a variety of forms. A distinction is made between 
participatory and nonparticipatory observation on the one hand, and between 
structured and unstructured observation in terms of the recording method on the 
other. 

Nonparticipatory observations make use of observers who record and document 
employees’ activities with their knowledge and consent, but do not take part in 
these activities themselves. In concrete terms, an observer could observe the 
activities of an entire organizational unit or an operational function, such as the 
work in a warehouse or the incoming goods department. The observer finds a place 
from which she/he can see and hear everything, but without disturbing the work. 
Another version would be to observe a single person in the enterprise as he/she 
carries out their operational tasks. Here, the observer would shadow the person 
under observation for a particular period of time in order to record their range of 
tasks and activities. This could for instance be used to document important practices 
that the observed individual carries out unconsciously. However, the act of obser- 
vation generally produces the effect that the behavior to be observed is altered by 
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the mere presence of the observer. “If people are aware that they are being 
observed, they automatically regulate their behavior” (Nerdinger 2008). This fact 
must be taken into account when evaluating the results of an observation, but is not 
generally an argument against the use of observation to supplement interviews, for 
example. 

With participatory observation, the observer not only observes what is happen- 
ing but also asks questions about it. This approach makes it possible to capture 
some of the tacit knowledge and to collect explanations, for example, about why 
certain things happen in a certain order or a certain manner. 

Observation can also take place in a structured or unstructured form. Structured 
observation is carried out following precise rules with respect to what is recorded 
about the subject under observation, as well as when, where, and how. For example, 
if carrying out structured nonparticipatory observation, details of who is observed, 
for which period of time and during which activities, and how the information is 
recorded will be predetermined. Unstructured observation is unsuitable for Enter- 
prise Modeling because this type of observation is used to formulate hypotheses, 
which are then verified in a hypothesis-testing process. This is not the purpose of 
Enterprise Modeling. It is to describe an enterprise, in its current or future state, in a 
model. 



4.3.3 Document Analysis 



In document analysis, electronic or printed information is viewed and ana- 
lyzed to obtain relevant findings for the purpose of modeling. 



Document analysis often provides a valuable contribution to Enterprise Modeling 
as it offers the opportunity to gain a relatively quick insight into the structures, 
tasks, processes, and communicative relationships in the investigated enterprise. 
Available documents that may be potentially relevant to the purpose of modeling 
are analyzed, and relevant enterprise knowledge extracted from them. These doc- 
uments could include organizational handbooks, standard operation procedures, 
quality manuals, legislation, organizational charts, service regulations, job descrip- 
tions, or flowcharts. 

Document analysis is generally a good starting point for an Enterprise Modeling 
project, but it can also provide important reference points for preparing, 
supplementing, or developing further investigations during the course of an ongo- 
ing modeling project. At the start of the project, potentially relevant documents 
should be requested from the enterprise by the modeling team. The documents 
provided are then evaluated, checked for contradictions, and filed for later use in the 
modeling process. Important findings should be documented separately. 
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Ambiguities, outstanding questions, and contradictions are either resolved with the 
client in advance or studied during further analysis and information gathering 
activities. 

During document analysis, it is important to be aware that the information 
represented therein may not be up to date, and must therefore be checked by 
performing at least random checks with other knowledge elicitation approaches. 

An example of document analysis with a slightly odd modeling purpose can be 
found in a project reported by Persson (1997). Textual requirements specifications 
were analyzed and the enterprise knowledge contained therein presented in the 
form of process models, actor models, goal models, concept models, and require- 
ments models. This was done in order to identify missing or contradictory infor- 
mation in the requirements specification. The models revealed numerous unclear 
aspects of the requirements specification. This indicates that Enterprise Modeling 
also can contribute to reviewing of requirements specifications. 



4.3.4 Self-Recording 



Self-recording is a knowledge elicitation approach where individuals enter 
information in preprepared forms during a specified period of time. 



Self-recording can be used to collect information about tasks, activities, time, and 
volumes. The involved stakeholders note the requested information themselves. 
Self-recording can be free-form, i.e., the stakeholders describe their field of work in 
their own words, without a predetermined structure. It can also be structured, where 
both the facts to be recorded and a form on which to do so are specified. As the 
information gathered from free-form self-recording takes considerable effort to 
evaluate, structured self-recording prevails in practice. This requires more prepa- 
ratory work, but the prestructured information is easier to evaluate, and the infor- 
mation collected is also, in general, more complete. 

To ensure that all participants collect the necessary information systematically 
and with comparable content, forms should be prepared and distributed to all the 
stakeholders involved, along with appropriate instructions for completion. For 
example, selected stakeholders who perform a particular role in the process at 
hand but who work at different departments or related organizations may record 
all the activities they perform by noting these down at the end of a task/time period 
along with details of the time and order. This would allow different sites or 
departments to be compared with the aim of standardization. 

Because the information is recorded without any monitoring by an observer, it is 
necessary to check its plausibility. In addition to tasks, working hours, and volumes, 
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communicative relationships can also be determined. For self-recording, the log- 
ging period should be clearly defined, and the method by which the collected 
information will be evaluated should also be taken into account when creating the 
forms. 



4.3.5 The Participatory Modeling Workshop 



In participatory modeling, a group of stakeholders of the problem at hand 
and modeling experts create enterprise models together. Each workshop has 
a specific goal and is facilitated by the modeling experts. 



The elicitation approaches presented in the preceding sections aim above all to 
collect information that contributes to an understanding of the current situation in 
the enterprise or of the future aims. This information is then used to create 
enterprise models, but these are not actually developed during information 
gathering. 

The participatory modeling workshop, on the other hand, is a knowledge elic- 
itation approach where the elicited information is immediately discussed and 
incorporated into an enterprise model (or discarded, if not relevant). 

A modeling workshop can consist of one or more modeling sessions of 1-3 h, 
each of which with its own specific goal, outline, and process. For instance, one 
session could focus on modeling the challenges of the enterprise related to a certain 
problem and the next on modeling the goals for the future state while a third session 
could model activities to achieve the goals. 

Particular attention is paid to participatory modeling in this book since the 
approach has proven to be particularly beneficial as an integral part of the 4EM 
method, the example Enterprise Modeling method described in this book 
(Chaps. 7-9). More on the arguments for adopting the participatory approach to 
modeling is included in Chap. 7. The use of the participatory approach in the 
context of a modeling project is discussed in Chap. 9. 

As the stakeholders concerned with a certain problem in an enterprise generally 
have the best knowledge of or ability to judge the current situation and potential 
avenues for improvements, their active involvement in modeling both the current 
situation and future improvements is particularly valuable. 

Participatory modeling aims to make these stakeholders active participants in 
model development and to achieve consensus between them regarding all modeling 
decisions, or at least to gain acceptance of the models created. Instead of merely 
acting as sources of information, the participants become active creators, which 
should result in the participants regarding the created models as their own achieve- 
ment, and not something developed by outsiders. 
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The participatory approach encourages participants to introduce their “own” 
modeling contributions, which are negotiated with the group of participants and 
then incorporated into an overall model that is accepted by the group. In addition to 
increasing the acceptance of the models among those involved, a further advantage 
of this approach is that models depicting design decisions about the future state of 
enterprise affairs are developed by the participants themselves, and can therefore be 
accepted and implemented more quickly. 

Participatory modeling workshops involve a moderator. During the workshops, 
the moderator should ensure that the participants’ attention remains focused on 
actually solving the problem at hand. Activities such as training in a particular 
modeling language are therefore not advisable, particularly in the early stages of 
modeling. 

Two groups of actors can be distinguished in participatory modeling: domain 
experts and modeling experts: 

• Domain experts have the necessary knowledge of the enterprise in question or 
domain and application context for the modeling purpose. These subject matter 
specialists know the organizational structure, business processes, responsibili- 
ties, regulations, or problems in the enterprise. This means that any member of 
staff, from an ordinary worker to executives and enterprise stakeholders, may be 
a potential domain expert. 

• Modeling experts have knowledge and experience of the Enterprise Modeling 
method used. They know both the model creation guidelines and the problem 
that the model is intended to solve. They are also experts in preparing and 
conducting moderated modeling workshops. Often, the method experts are 
engaged from outside the enterprise, not internally. 

The modeling experts are also tasked with planning the entire modeling project 
and agreeing on concrete modeling workshops or other preparatory analysis and 
information gathering activities with the commissioning party in the enterprise. 
Among other things, the modeling experts are also responsible for selecting an 
approach that is suited to the modeling purpose, and for ensuring that the resources 
provided are used in such a way that the project achieves the agreed goals within the 
allotted time. 

In both groups, it is possible to single out several roles that can be involved in 
modeling workshops. In the modeling expert group, these are: 

• Moderator (or facilitator): moderates the workshop and is responsible for ensur- 
ing that the selected Enterprise Modeling method is correctly implemented. A 
workshop may have multiple moderators who take turns during the workshop 
and focus on different aspects. Large projects in particular may have several 
moderators in the same group of modeling experts, but one of these must then be 
designated as the leader to clarify who is responsible for the overall success. 

• Tool operator: digitalizes the model developed during the workshop and assists 
the facilitator with moderating. This assistance may involve active listening or 
putting forward supplementary questions regarding information or relationships 
between the modeling elements. 
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• Minute taker: takes additional notes during the moderated workshops, which are 
used afterwards to document the decisions made or record the reasons for 
particular agreements between the participants. 

Together, the modeling expert group is tasked with ensuring the quality of the 
modeling process in each modeling session and the quality of the model itself 
(Fig. 4.1). 

The domain expert group should generally include representatives from different 
departments and domains, completely covering the enterprise and domain knowl- 
edge required for the modeling purpose. The domain experts are responsible for 
ensuring that the model content is technically correct and valid for solving the 
actual problem. 

A facilitator should meet various requirements (see also Moody and Shanks 
2003): 

• Method expertise: confident and unobtrusive use of the most important moder- 
ation techniques 

• Flexibility: workshops not planned too rigidly 

• Social sensitivity: a real instinct for when to hold back or intervene in discus- 
sions and critical situations 

• A natural style: no painstakingly studied and assumed behavior 

The facilitator may come from outside as an external consultant, or from within 
the enterprise in question. The advantage of an internal facilitator is that they will 
be familiar with the enterprise and the organizational unit under examination. 
However, an in-house facilitator is not independent of internal authority structures 
and objectives, which can make an unobtrusive style of workshop facilitation more 
difficult. By contrast, a facilitator brought in as an external consultant is impartial to 
enterprise goals and can bring new ideas and opinions to the enterprise from an 
outside perspective. 




Fig. 4.1 Responsibilities in a modeling session (Persson 2008) 
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Fig. 4.2 Resources for participatory modeling workshops 



The advantages of a moderated workshop (as opposed to interviewing partici- 
pants individually, for example) are that information from across the entire range of 
necessary topics can be obtained in a single event, and agreed among the partici- 
pants. There are also potential benefits even if the work does not involve clearly 
distinct topics, as many different perspectives can be contributed and the various 
participants can generally draw on different individual experiences. 

Prior to a workshop, its goals and topics should be clearly defined and the 
necessary participants identified and invited. The facilitator must prepare the 
structure of the workshop and its sessions, i.e., plan the desired order of events so 
that this can be used as a basis for moderation. See Chap. 9 for more detail about 
preparing for the modeling workshop. 

At the start of the workshop, the facilitator introduces the theme and objectives. 
During the workshop, it is useful to use a range of resources to facilitate moderation 
and participation (Fig. 4.2). Examples include pin boards, flipcharts, moderation 
paper, pens, moderation cards, pins, PC, or beamer and screens. There should be 
sufficient resources available to ensure there is no need for interruptions during the 
workshop. 

The participatory modeling workshop may include the following sub- steps or 
tasks, which are carried out according to the structure planned in advance by the 
moderator: 
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1 . Card questions 

All participants simultaneously write down on a card their answers or ideas 
regarding a specific question asked by the moderator. The cards are collected and 
the results are displayed on a plastic wall (see Sect. 5. 1. 1) in a structured manner. 
The moderator can evaluate the resulting content with the group, and add to it if 
necessary. 

2. Brainstorming with cards 

The participants are given a specific number of cards by the moderator. The 
more cards, the more creative the participants can be. On these cards, the 
participants should then write down their thoughts and issues regarding 
the defined questions, using short sentences. 

3. Creating clusters 

The resulting cards are discussed one at a time by the group and divided into 
particular subtopics or problem areas, also known as “clusters.” Individual 
questions or problems that are mentioned more frequently in the clusters should 
be marked and weighted. When clustering is complete, the facilitator can decide 
with the group whether any additions are necessary if particular aspects or 
criteria have been disregarded. 

4. Grouping clusters 

With the help of the group, the facilitator groups the individual clusters by 
assigning headings to them. 

5. Ordering clusters 

A table is produced listing the individual clusters according to their weighting. 
This table is used to sort clusters by importance or urgency. 

6. Breaking out into subgroups 

The participants are divided into subgroups, each of which deals with a 
cluster. The concrete tasks involved in this work depend on the goal and topic 
of the workshop. The results obtained are presented by each subgroup to the 
other subgroups. 

7. Evaluation 

The working group results are presented by the group participants. Open 
questions and further steps are discussed and agreed with all workshop 
participants. 



Chapter 5 

Enterprise Modeling Tools 



This chapter focuses on EM tools for the use in EM projects supporting basic 
analysis techniques (discussed in Chap. 4) and development of the different model- 
ing perspectives and sub-models of the enterprise model (presented in Chap. 8). The 
tools used to support EM do not include only IT-based applications for 
documenting models. Traditional aids, like flip charts, the “plastic wall,” and 
paper-based modeling, are also used during modeling workshops. 

Computerized modeling tools are subject to continuous development and 
improvement and the objective of this chapter is not to advocate any specific tool 
or vendor. Instead we will discuss a number of useful core features that are offered 
by many modeling tools. We will introduce different tool categories including 
examples for each category. The last section of this chapter discusses the issues 
of EM tool adoption in organizations, which becomes important once an organiza- 
tion decides to use EM in a more institutionalized way, without relying on external 
experts for support. 



5.1 Basic Tools 



In this section we will discuss EM tools needed to support the creative process of 
the modeling workshop. Regardless of the purpose of modeling, the models need to 
be documented for further work or at least for the workshop minutes and capturing 
the results achieved. 

There are two basic approaches to capturing models during an EM workshop: 

- Using simple tools such as the “plastic wall” or paper flipcharts, or 

- Using a beamer and computerized tool for modeling or drawing. 

This choice depends on a number of factors and objectives of the modeling 
workshop, which we will discuss in the following two sections. 
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5.1.1 Simple Tools and The “ Plastic Wall” 



The so-called “plastic wall” approach means that models are documented on large 
plastic sheets using colored paper cards. The “plastic wall” (for an example see 
Fig. 5.1) is then viewed as the official “minutes” of the modeling session. The 
advantages of this approach are that the plastic wall can be set up in almost any 
room with a sufficiently large and flat wall and that it allows the modeling 
participants to view the model independently of the tool operator or other external 
support. The participants can come closer to the model to view certain details, point 
at them, or engage others in a discussion. They can also improve the model without 
disturbing each other, if the modeling situation requires so (see Fig. 5.1). Further- 
more, all actions of the modeling facilitators are visible and understandable. 
Compared to a computerized tool, the plastic wall often has advantages in creative 
modeling situations: with a computerized tool the facilitator or tool operators often 
need to perform “housekeeping” actions such as saving, changing font size, line 
size, adding more pages to the drawing, etc., which shifts people’s attention and 
disrupts the creative flow of the workshop. However, after the modeling seminar, 
models on the plastic sheets should be documented with a computerized tool. 




Fig. 5.1 Using the “plastic wall” — everyone is involved in modeling 
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The “plastic wall” approach is more suitable when 

- The purpose of the workshop is to innovate — to create and capture new knowl- 
edge and to document it in the model form. 

- The modeling workshop takes place at a location where using a beamer is 
impractical, e.g., due to travel plans or layout or the room. 

- Many participants shall be involved and be able to contribute to the model at the 
same time. 

- Different alternative options need to be discussed and explored in modeling. 

In the context of using the “plastic wall,” we would like to point out two 
common misconceptions: 

- There are some people who see this as somewhat unserious way of working. 
Perhaps due to the fact that many organizations have invested large amounts in 
equipping their meeting rooms with several beamers, smart boards, multiple 
displays, and other hardware and, hence, are eager to use this equipment. In our 
experience, the inclusive nature of modeling with the “plastic wall” outweighs 
the drawback of needing to document the model in the tool afterwards. Further- 
more, the advanced features of the computing equipment often serve as 
distractors from the problem solving and modeling tasks at hand. 

- There are brainstorming and business planning approaches using large paper or 
plastic sheets for capturing ideas or documenting the discussion. They share 
some similarities with participatory EM and 4EM and as a result some partic- 
ipants may approach the 4EM workshop with some skepticism thinking that it is 
just another idea generation session. To avoid this, the facilitators should point 
out the main differences, e.g., the modeling notation, the specific way of working 
(e.g., the consensus-driven discussion, focus on concrete actions), and the role of 
the modeling facilitator. 

5.1.2 Using a Beamer to Support the Modeling Session 

The “plastic wall” wall is more suitable for capturing the initial version of a model, 
i.e., innovate and creative modeling activities, but once the model has grown and 
been discussed for some time, e.g., at the second modeling session, the changes 
need to be introduced in a model that is documented with a computerized tool. 
Between the modeling sessions there might also be the need to produce reports or 
presentations slides, which also requires that the model is documented electroni- 
cally. Hence, once the models reach the level of completeness where mostly 
refinements need to be done, the modeling workshop should be supported by a 
beamer and computerized tool. 

In this case, at the modeling seminar there should be two persons driving the 
process — facilitator driving the discussion and tool operator (or assistant facilitator) 
focusing on supporting the discussion by displaying the right part of the model at 
the right time and introducing changes suggested during the meeting. The effort and 
skill that it takes to perform these tasks efficiently should not be underestimated. It 
is highly recommended that the facilitator and tool operator rehearse their 
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Fig. 5.2 A modeling session focusing on model refinement 



presentation of the model in advance; they may also need to prepare the models for 
presentation purposes by adjusting text size and colors. 

Figure 5.2 shows a situation of a modeling session using a beamer and a 
computerized modeling tool. On the right-hand side we can see a plastic wall 
model with the initial model that set the overall objective of the modeling engage- 
ment. A small portion of the computerized model is shown on the left-hand side. 
Displaying both models side by side helps clarifying the way of transforming the 
model on plastic into the computerized model and supports the shift to the com- 
puterized model version. In this particular case the initial model consists of less 
than 20 model elements, but once applied to the whole problem domain in the 
organization, the model exceeded 100 elements. In this case using the “plastic wall” 
approach for the whole problem domain would have been impractical. 

In summary, using a beamer and a computerized tool is suitable when: 

• The purpose of the modeling workshop is to review and/or refine existing models 

• The new model is to be created by reusing fragments of existing models and/or 
integrating patterns. 



5.2 IT Tools 

IT tools and computerized tools provide an important support for various activities 
in EM, in principle aiming at covering all modeling phases. These tools can roughly 
be categorized into simple drawing tools and advanced tools, such as fully devel- 
oped modeling environments. This section will briefly introduce both categories. 
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5.2.1 Simple Drawing Tools 



Enterprise Modeling has historically evolved independently from tools. This can 
perhaps be explained by the fact that many contributors to the EM area were 
practitioners focusing on real application projects. Hence, they got accustomed to 
using whatever tools they already had. In addition, the advances in EM during the 
first part of the 1990s were more rapid than the advances in CASE tool and meta- 
tool development, particularly with respect to support for various modeling 
approaches and method customization. The EM projects of those days were of 
small to medium size with simple documentation requirements, which did not 
require a model repository. As a result the EM community of practitioners widely 
adopted simple drawing tools such as iGrafx Flowcharter™ and Microsoft Visio™. 
This choice was motivated by the following requirements to EM tools: 

• The need to integrate with Microsoft Office™ software, such as Word for 
including models in reports, and Microsoft PowerPoint™ for inclusion of 
models in presentations. 

• The need to print out models in large formats. If only A4 format is available for 
printing, these types of tools allow distributing it over a number of pages that can 
then be glued together thus forming a large model. 

• The need to export models to popular graphical formats in order to present them 
on the web. More advanced modern tools offer significant automation possibil- 
ities for web-based model presentation. 

• The need to create new graphical symbols for certain modeling components. 
Simple drawing tools support this functionality, which is an easy way to provide 
minimal support for a modeling method. 

Requirements to EM tools that have become significant as the field of EM 
becomes more mature are: 

• Model repository support. For simple projects this is not crucial, but if an 
organization wants to institutionalize EM then a repository is needed. 

• Model export and presentation in web-based format, for example, for presenta- 
tion on the corporate intranet in order to communicate business processes among 
the employees. 

• Model analysis and quality checking, e.g., by creating user-defined views of the 
model or executing queries over the content of the modeling components. 

• Model maintenance over time, which in essence, can be called as keeping 
models “alive,” i.e., up to date and relevant for the users. 

• Model reuse, e.g., by defining reusable model chunks and/or patterns. 

• Model execution and integration with other applications allowing these appli- 
cations to be configured by models. 
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Most of the above requirements are cumbersome to fulfill with tools like 
Microsoft Visio™ or iGrafx Flowcharter™ and if these requirements are relevant 
for the organization, then a more advanced modeling tool is needed. 



5.2.2 Advanced Tools 

The decision of whether EM is dependent on a number of factors. The use of 
modeling environments is recommended 

• If models are intended to be maintained and/or reused for a prolonged period, 

• When several people at different locations are involved in a modeling project, 

• If parts of the model must be reused or integrated into other models, or 

• When the correct use of modeling languages or compliance with standards must 
be guaranteed. 

This section covers typical modeling environment functions, which can vary 
greatly between commercially available tools depending on their focus or target 
group. 

Besides actually allowing models to be created and edited, the functionality of a 
modeling environment may also include the following functional components: 

• (Multiple) modeling language support 

• Modeling view and level concepts 

• Model storage (in repositories if applicable) 

• Modeling method support, e.g., modeling process guidance 

• Tool customization and extensibility 

• Model analysis and manipulation. 

A brief description of these functional areas is provided below. Additional basic 
tool functions that are not exclusive to modeling environments, such as user and 
rights management, help functions, or license management, are not included in the 
following outline. 



5.2.2.1 Modeling Language Support 

The modeling language defines what (mostly graphic) elements are allowed when 
modeling, what relationships are permitted between these elements, and what 
meaning they and their attributes have. The modeling tool should then ensure that 
the rules and guidelines provided by the language are obeyed. Most commercially 
available modeling environments focus on a single modeling language, which 
means that only models in that modeling language are possible. A few tools support 
multiple modeling languages or the development of a new dedicated modeling 
language. This process is known as meta-modeling and tools supporting this 
functionality as meta-tools. In this situation, “multiple modeling languages” does 
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not mean that different languages can be used in the same model, but that the tool 
allows models to be created in a choice of different languages. 



5.2.2.2 Model Creation and Editing 

The most important functional area for any modeling tool is model creation and 
editing. This is where the graphic modeling elements and inter-element relation- 
ships available in the selected modeling language are provided by the tool and can 
be edited using standard graphic tool and editor functions. These include creating, 
organizing, interconnecting via relationships, manipulating, deleting, defining 
properties (labels, attributes), and so forth. To this end, most modeling environ- 
ments provide a graphic user interface with text input fields for properties. Many 
tools facilitate model creation by automating recurring tasks, for instance, laying 
out the model according to a predetermined pattern or automatically formatting 
labels of modeling components. Some tools also provide context-sensitive func- 
tions such as only offering the relationship types allowed by the modeling language 
when creating a relationship between two modeling elements. 



5.2.2.3 Views and Levels 

Views and levels is an area of tool functionality for structuring large and complex 
models. They also simplify the use of such models and facilitate model navigation. 
Views help to reduce complexity by including only the specific aspects required, 
rather than the entire model. For example the “process view” for a model that 
contains processes, organizational structures, products, and IT systems would only 
show the model’s processes and the information relevant to them and hide the other 
elements of the model. Many modeling environments offer views as part of their 
functionality. However, the specific views available will generally depend not only 
on how aspects of an enterprise can be depicted in the modeling language, but also 
on what method is used. The EM perspectives presented in Chap. 4 can also be used 
as views. In addition to these thematic views, some tools also use the view concept 
to define sections of the enterprise based on the organizational structure. In this 
case, a view might contain only one particular organizational unit, or one particular 
process that passes through several organizational units. 

Levels are used in modeling tools to allow certain modeling elements to be 
refined and to manage the representation of refinement levels. In process modeling, 
for example, an overall business process is often modeled first as a sequence of 
individual activities to be carried out, without immediately splitting these activities 
into sub-activities. In a further step, which would equate to an additional level for 
the purpose of refining the individual activities, the actions to be carried out as part 
of these individual activities are described. The number of refinement levels is 
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unlimited in principle, but may be restricted by some tools. A similar type of 
refinement can also take place when modeling product structures and services. 



5.2.2A Model Storage and Repository 

Every modeling environment’s functionality must include storing the models that 
have been created. There are differences in the method of storage. The most 
common form is to save the models as files in the computer’s file system — an 
approach that is common in office applications and drawing tools. This form of 
storage generally assumes that a model will only be edited by one person at a time. 
In terms of storage format, it is common to find proprietary formats that are specific 
to the tool manufacturer and often have an unknown type of storage structure. The 
simple drawing tools used for EM typically support this way of model storage. 

When working on extensive modeling projects with more than one modeler, it is 
advisable to make use of the additional storage support offered by some modeling 
environments in the form of model repository. Here, individual models are not 
stored in the file system, but in a type of database through which access to 
individual model or its parts is coordinated. This means that more than one person 
can work on the same model as long as they do not simultaneously edit the same 
model elements. Sub-models or model views are frequently defined for this pur- 
pose, with each sub-model or view only available to one user at a time. Some 
repository solutions also allow storing different model versions, which means that, 
if necessary, previous versions can be opened or the differences between versions 
can be displayed. 

In addition to storing models in file systems or repositories, some tool environ- 
ments also offer cloud storage, which is provided as an Internet-based service and 
does not involve the user knowing the exact storage location. 

5. 2.2.5 Method Support 

The modeling method specifies what steps should be carried out when creating a 
model, and how the aspects of an enterprise that are relevant to modeling can be 
identified and captured in model elements. Some modeling tools are tailored to a 
particular modeling method, which means that they support not only the modeling 
language, but also the steps prescribed by the modeling method. This often becomes 
evident when the method prescribes a sequence for modeling different views of the 
enterprise, such as modeling business processes first, followed by modeling organi- 
zational structures and then modeling information structures. Needless to say, using a 
tool designed for a specific method requires detailed knowledge of the method 
concerned. This should be taken into consideration before selecting such a tool. 
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5.2.2.6 Customization and Extensibility 

Many tool environments allow basic adjustments to be made to the tool during 
installation, e.g., for all employees in an organization, as well as allowing individ- 
ual settings to be altered for each modeler. Typical customization options include 
showing or hiding particular menus, defaults for the font and size of text in model 
elements, toolbar or information positioning, default file or repository location and 
autosave settings, color choices for certain interface elements and inclusion of the 
company logo, and defaults for both the modeling language and the modeling 
method (if applicable). 

Only a few tools offer the ability to extend modeling environments, for 
example, by adding internally developed functions for importing or exporting 
data, as this requires a built-in scripting language for coding such extensions or a 
programming interface and the disclosure of storage structures. Tool extension 
options are primarily used by large enterprises that utilize modeling environments 
on a permanent basis to support IT management, or that conduct long-term 
modeling projects. 



5.2.2.7 Model Analysis and Manipulation 

Model analysis is an area of modeling tool functionality with content and scope that 
is highly dependent on the modeling language. With semiformal languages, it is 
often only possible to analyze compliance with fundamental composition and 
design rules, which might include rules for which elements can be connected and 
what relationships can link them, or which elements can follow certain others. 
However, formal modeling languages allow further analysis, making it possible to 
check the resulting models for modeling language errors, identify refinement errors 
on different modeling levels, and test a model’s completeness or translatability to 
other notations. Modeling languages that capture data or material flows also allow 
the represented flows to be checked for correctness and consistency. In models with 
control structures, it is possible to determine whether deadlocks may occur when 
executing the model or to check if some parts of the model cannot be reached during 
execution, meaning that they have been incorrectly modeled. 

Model manipulation functions often relate to the entire model or all elements 
of a particular type as defined by the modeling language. Examples of manipu- 
lation functions include adjusting the model layout according to predefined 
rules, transforming the model into another modeling language, creating other 
model presentation formats, or manipulating attributes for all elements of the 
same type. 
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5.3 Selecting Tools 

The practical aspects of tool acquisition are often neglected and as a result tools are 
acquired and used in haphazard manner. This has created many problems, particu- 
larly for inexperienced companies that have tried to use EM tools, perhaps assuming 
that the tool will be “magically” responsible for performing the analysis and 
suggesting a suitable solution to their business problem. Many tools have been 
purchased but insufficiently used. The purchases made without a proper analysis 
and planning have led to a situation that the tools purchased do not meet the 
expectations of the company that bought it. As a result, they turn into “shelf-ware,” 
and companies keep looking for new tools. In most cases the negative experiences 
concerning tools are caused by the lack of proper understanding of how to use the EM 
tools and how to introduce them in an organization. Furthermore, novices in EM 
might even be unaware of their lack of knowledge and skill in EM methods and tool 
usage. Hence, sufficient understanding of EM is particularly important in the stages 
of acquiring EM methods and tools. 

Exactly which types of tools and which software packages are useful is deter- 
mined by (1) the organization’s intentions (e.g., will the models be kept “alive”), 
(2) situational properties (e.g., the presence of skillful tool operators, availability of 
resources), and (3) the specific functions that the tool should serve — tool require- 
ments. More about how to select and introduce EM tools in organizations is 
available in (Stima 2001). The remainder of this section outlines an EM tool 
acquisition strategy. 

The proposed tool acquisition process consists of three main phases — assessing 
the organization, choosing the EM tool acquisition strategy, and following the 
chosen strategy (see Fig. 5.3). 



5.3.1 Phasel : Assess the Organization 

Determine organization s objectives for EM. At this stage intentional factors are 
assessed and organization’s EM process reviewed. Intentional factors are those 
generic objectives of the user organization that can be used to determine the most 
appropriate EM tool acquisition strategy. The following intentional factors should 
be assessed: 

• Modeling without external consultants. This intentional factor reflects the orga- 
nization’s intention to develop its own EM competency and to use EM without 
help from outside EM consultants. 

• Keep models alive. This intentional factor reflects the organization’s intention to 
constantly update enterprise models, to disseminate them on the corporate 
intranet, as well as to use modeling as a part of standard business development 
and execution processes in the organization. 
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Fig. 5.3 Overview of the EM tool acquisition process 



• Changing intentions . The organization has to be aware of how often the EM 
tool-related intentions change and what the rationale for the change is. In reality 
practical and impractical arguments are often mixed, but nevertheless the orga- 
nization should assess the potential for future changes. 

• Purpose of Enterprise Modeling. This intentional factor determines what kind of 
tool the organization needs to acquire (e.g., developing and configuring IT, 
disseminating best practices on the intranet). It determines the requirements 
for the EM tool. 

Assess the situation in the organization focusing on a number of situational 
factors. Situational factors “are those properties of the problem situation that can be 
used to determine the most appropriate problem solving strategy. This includes 
those properties that can have an impact on the type of uncertain effects which may 
occur and their adverse consequences” (Euromethod 1996). The following situa- 
tional factors should be assessed: 
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• Method usage maturity — determines how experienced and prepared (in terms of 
competencies and skills, work processes, and roles) the organization is to work 
with modeling methods of this kind; 

• Method stability — determines how frequently new versions of the modeling 
method will be introduced; 

• Tool usage maturity — determines the organization’s experiences and ability to 
use computer-based tools for supporting modeling methods; 

• Tool development maturity — determines the organization’s ability to develop 
computer-based EM tools. This situational factor should be taken into account 
only if the organization has the intention to develop new EM tools. 

• Complexity of the envisioned EM projects — indicates the kinds of problems that 
will be addressed by EM, the variety of tasks to be performed, and results 
expected from the project; 

• Project resources such as time, competent personnel, and money are the critical 
success factors of any EM project and therefore should be considered in EM tool 
acquisition process. 

Elicit and prioritize requirements for the EM tool. These requirements include a 
number of interrelated categories, such as EM support requirements, 
customizability and extendibility requirements, requirements for the modeling 
repository, modeling data visualization requirements, reporting and querying 
requirements, collaborative work requirements, requirements for integration with 
other tools and information systems, as well as nonfunctional requirements. 



5.3.2 Phase 2: Choose EM Tool Acquisition Strategy 

At this stage the candidate EM tool acquisition strategies are assessed and the most 
suitable chosen and then followed. These generic EM tool acquisition strategies 
were elaborated on the basis of CASE tool adoption strategies defined by Bubenko 
(1988). The following set of EM tool acquisition alternatives should be considered: 

• Outsource the EM tool-related tasks to an external consultant, or 

• Use a simple diagramming tool for documenting the modeling results, or 

• Acquire an EM tool within the organization, by following one of the EM tool 
acquisition strategies: 

1. Develop your own EM tool-set 

2. Order your own EM tool- set from a tool vendor 

3. Integrate several available EM and CASE tools 

4. Purchase a method specific tool 

5. Customize meta-tool into an EM tool. 
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5.3.3 Phase 3: Follow the Chosen EM Tool Acquisition 
Strategy 



At this stage the newly acquired tool is tested in the organizational setting, usually 
in a pilot project, in order to validate its suitability. If the EM tool proves to be 
useful, the organization should decide on its institutionalization strategy. Besides 
procurement of the EM tool itself, the organization should also have the compe- 
tency to work with it. Our position is that without the necessary EM competency it 
is more rational to hire a consultant who provides the tool support. Competency 
issues of EM projects are discussed in Chap. 10 and the issues related to adopting 
EM within an organization in Chap. 11. 



Chapter 6 

E-Commerce Case Study 



This chapter discusses different aspects of a small business, which will serve as case 
study in this book. The case will be used for demonstrating and explaining various 
aspects of the 4EM method. The case is based on an imaginary company called 
“Accessories 4 you” (A4Y). A4Y is an e-commerce company specialized in 
accessories and jewelry with individual engravings. Sales and distribution of the 
products primarily are based on the company’s e-Shop (“online shop”), but A4Y 
also runs a conventional shop that offers services such as personal guidance, 
product demonstrations, and direct sales. 

The content of the chapter is the description of the current situation (as-is 
situation) of the case study company, which includes the established processes 
and organization structures. In order to prepare the company for future market 
challenges and organizational changes, first the current situation should be modeled 
and used to identify problems, opportunities, and change needs. Afterwards, the 
future situation (to-be situation) has to be designed and modeled. As-is and to-be 
models are presented in Chap. 8 in order to illustrate how EM can be used in a 
change management situation. 

The introduction of the case study company A4Y is divided into two parts: 
Sect. 6.1 describes the as-is situation of the company’s primary processes, i.e., the 
processes directly related to production and distribution (e.g., inbound and outbound 
logistics, operations, customer services, marketing and distribution). Section 6.2 
describes the current situation of the supporting processes (e.g., procurement, 
human resource management, and technology development). 



6.1 Primary Business Processes 

A4Y is an e-commerce enterprise specializing in sales of accessories and jewelry 
with individual engravings. Marketing, sales, and distribution of the products are 
mainly realized using the e-shop (online shop) of the enterprise. The enterprise has 
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a branch office colocated with a conventional shop in which the customers can get 
personal advice and purchase products of A4Y. All products of the enterprise are 
manufactured at the facilities of the enterprise. On request the products can be 
provided with an individual engraving. The branch office receives all orders made 
via the e-shop and prepares them for delivery. The deliveries of products are carried 
out by an external shipping service provider. If the branch office receives an order 
for a product with an engraving, the engraving text is forwarded to the manufactur- 
ing unit. Subsequently, the selected product is engraved with the text in the 
manufacturing unit and is shipped directly from this location by the shipping 
service provider. 

In the following the primary processes of A4Y are described, which include the 
activities of inbound logistics, operations, marketing and sales, outbound logistics, 
as well as customer services. 

Inbound Logistics The activities of the inbound logistics are reception, storage, 
and distribution of working funds required to manufacture products or create 
services. The inbound logistics is mainly focused on the physical inputs that are 
supplied to the enterprise, e.g., individual parts for the production of accessories. 
The following activities are part of the inbound logistics: conducting a comparison 
of deliveries, unloading of incoming goods, completeness check of goods according 
to the freight documents, ascertainment of possible damage in transit, unpacking of 
goods, repacking goods in storage means, incoming goods inspection (e.g., quan- 
tity, quality, meeting deadlines). The inspection of incoming goods of the physical 
inputs belongs to the inbound logistics as already mentioned. The inspection takes 
place at random for goods with a value of less than 100 €. Each item with a higher 
value is controlled without exception. If a defect in the delivered goods is discov- 
ered, it has to be reported immediately to the general manager upon the receipt of 
goods. The general manager reports this defect to the supplier and orders a new 
delivery as replacement of the defect goods. All goods with no defect are registered 
into the stock system of the inbound logistics. 

Operations The operations of A4Y include manufacturing processes of final goods 
carried out at the manufacturing unit which is in close vicinity to the office of the 
enterprise. A manufacturing process is triggered by a manufacturing order created 
in the branch office or e-shop. The manufacturing order is placed if a customer 
would like to have a product with an engraving. Furthermore, a manufacturing 
order is issued by the branch office if the quantity of standard goods in stock of the 
branch office is less than the defined minimum. The generic term “manufacturing 
process” contains several subprocesses that have to be conducted in order to 
manufacture a product. In the first step a sample blank is embossed or laser- 
engraved if a manufacturing order for the production of standard goods exists. 
The sample blank is checked for faults in the next subprocess. If the sample blank is 
faulty, a manufacturing order for this product has to be placed again. Currently, the 
number of sample blanks with faults is increasing. Potential countermeasures would 
be to increase the maintenance efforts for the production machinery or to acquire 
new production equipment. The general management did not decide yet, which 
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countermeasure to implement. Currently, there is a tendency of the management to 
increase the maintenance efforts, as the acquisition of new production equipment is 
quite costly and probably not a viable option for the company. 

If the sample blank does not have any faults, it can be used to produce standard 
products according to this sample blank. Depending on the sample blank, these 
standard products can also be decorated with a motif. The quantity to be produced 
depends on the production orders. For standard products which are frequently 
ordered by customers, A4Y produces more items than actually ordered and puts 
them into stock in order to be prepared for larger orders and for manufacturing 
orders including engravings. The management defined as a rule that manufacturing 
of standard products with engravings must not take more than two weeks. If a 
manufacturing order arrives which includes engraving a text, the manufacturing 
unit first has to check whether it is technically possible to produce the engraving. 
For this purpose manufacturing guidelines have been developed. These guidelines 
contain restrictions regarding the maximum number of symbols, the permitted 
fonts, and the size of the engraved text. The standard product is only engraved 
with the customer’s text if these guidelines can be followed. If the guidelines are 
violated, the order or the text to be engraved has to be modified. Such a change 
requires the agreement of the customer and the general manager. When the engrav- 
ing is finished, the product is prepared for delivery and handed over to the external 
shipping service provider. 

Furthermore, the general management defined as a long-term goal to reduce the 
operating costs by approximately 15 % and as short-term goal to increase profits by 
10 % this year. In order to reach these two goals, an organizational change process 
has to be initiated, which will have to include decisions about investments in new 
product variations and about measures to cut costs. 

Marketing and Distribution The distribution of products currently is carried out by 
external shipping service providers. A4Y has to hand in the goods to be delivered at 
a branch office of a shipping service provider. The general management wants to 
improve the situation by negotiating a long-term contract with one of the shipping 
service providers. The contract is supposed to include that the shipping service 
provider in the future will collect the goods to be delivered at A4Y’s branch office 
two or three times a week. Such a contract is expected to contribute to cost 
reduction because shipping service providers offer better conditions and lower 
prices for long-term agreements with a certain shipping volume. Furthermore, it 
will save time for A4Y if the goods are collected by the provider instead of having 
to hand them in. 

In marketing, two main processes have to be distinguished: online marketing and 
off-line marketing. The following activities are carried out by the marketing 
department of A4Y in online marketing: 

Search Engine Optimization (SEO): The marketing department continuously adapts 

the content of A4Y’s website in order to achieve a better indexing by Internet 

search engines. The aim is to be listed in the top of the search results when 
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potential customers search for A4Y’s product categories. Furthermore, links are 
set between A4Y’s website and the websites of relevant partners. 

Search Engine Marketing (SEM): A4Y books particular keywords at various search 
engine providers. If a user does a search for one of the keywords, the search 
engine returns the link to the e-shop of A4Y as the top search result. 
Newsletter. A newsletter is created with the help of the marketing department 
presenting the sales campaigns and the current developments in the enterprise 
to the customer. 

Furthermore, the marketing department tries to increase the customers’ interest 
for accessories with engravings using off-line marketing. The following activities 
belong to the offline marketing process: 

Sales talk: The sales staff of the branch office and the general manager are trained 
by the marketing department. The general manager often has sales talks with 
major customers and the marketing department expects that more sales talks can 
be successful with the help of this training. 

Brochures'. Product brochures are distributed at promising locations, e.g., at loca- 
tions where people spend time while waiting (e.g., hairdressers, dentist offices, 
railway stations). 

Poster. Posters with the current products and special offers are placed in appropri- 
ate places on streets and in shopping malls. 

All marketing activities are designed for attracting the customer’s attention. A 
performance review takes place after carrying out the online marketing activities 
with the help of Google- Analytics. The online marketing measures can be evaluated 
and improved by this performance review. Currently, there is no performance 
review for the off-line marketing measures. The general management plans to be 
more active in social networks (e.g., Social Media Marketing (SMM)) due to the 
fact that social networks are becoming more and more popular. For the marketing 
budget, the decision was made to not define a fixed amount for every year but to link 
the budget size to the annual turnover. More concretely, the budget for marketing 
measures was limited to a maximum of 10 % of the last year’s turnover. 

Outbound Logistics The outbound logistics basically describes all functions of the 
enterprise which deal with the physical distribution of products to the customers as 
well as the functions associated with that. A4Y has a process that deals with 
invoicing and the packaging of ordered goods. The activities of this process are 
for example order backlog administration, consignment sale, and if necessary order 
grouping. The products have to be packaged in such a way that the package meets 
the drop test guidelines according to ISO 2206. 1 The different regulations of this 
standard have to be observed during the entire process. For instance, the following 
information is mandatory for accounting: the name and address of the addressee, an 



1 ISO standard 2206 on “Packaging — Complete, filled transport packages — Identification of parts 
when testing.” For more information, see http://www.iso.org/ 
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unambiguous invoice number, the invoice date, as well as an overall view of the 
purchased goods with their net prices/gross prices depending on the receiving party 
(consumer/enterprise) — the reporting of the sales tax value (tax rate) is important 
for the presentation of prices. Furthermore, the customer is informed about the 
payment terms and revocation options. Before the goods are handed in for shipping, 
a suitable shipping service provider has to be chosen depending on the package size 
and the receiving country. The insurance value of the package depends on the 
invoiced value of goods. 

Customer Service The customer service encompasses all activities to maintain the 
value of the product for the customer. A4Y tries to stand out from their competitors 
on the market and to support the own marketing activities by offering additional 
services such as a telephone hotline for customer questions or a product 
configurator. A4Y offers different services on its e-shop platform, e.g., a telephone 
hotline, dispatch information for ordered goods, and an extensive product catalogue 
search, to encourage the customer to buy the goods of the enterprise. In the branch 
office additional services are offered, such as product demonstration and advice 
regarding engravings. A4Y strives for short delivery times so that the manufactur- 
ing process of a standard product and its delivery to the customer do not exceed 
two weeks. This is a relatively short time for this kind of customized product. 



6.2 Supporting Business Processes 



The section describes the current situation of processes with supporting function for 
the primary processes. This includes activities such as procurement, technology 
development, human resources, and general management. 

Procurement Procurement in A4Y includes the acquisition of goods and services 
from external sources which are needed for operations. Currently the procurement 
process in the manufacturing unit is activated if the stock of individual parts is less 
than the minimum stock. The procurement process starts with an Internet enquiry to 
choose the most favorable supplier for the different goods or parts to be procured. 
As a consequence, many small orders are placed at different suppliers with different 
delivery times and often varying quality. A supplier will not be considered for 
procurement processes in the future if the goods delivered do not meet A4Y’s 
minimum quality requirements. The requirements, which have to be taken in 
consideration, are availability of goods, short delivery times, correct delivery 
according to the order, conformity to established standards or norms, as well as a 
quick response time. 

The general management decided to change the procurement process by intro- 
ducing more extensive IT support with focus on the overall logistics process. The 
future IT support is supposed to register all changes in stock of the manufacturing 
unit and the branch office. If the actual stock is less than the defined minimum 
stock, the general manager has to receive a notification from the IT system. 
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Furthermore, the goal is to closely integrate A4Y’s IT system with the frequently 
used suppliers by setting up of a Supplier-Relationship-Management (SRM). The 
SRM is supposed to manage all data regarding products in stock, possible risks, 
conditions, or quality. The launch of SRM should help setting up a network of 
regular suppliers. Thus, the many small orders can be replaced by a lower number 
of bigger ones and the delivery times can be reduced as well. The regular suppliers 
should be selected according to meeting the minimum requirements for quality. 
Regular suppliers, who deliver a shipment of bad quality twice, should be put on a 
blacklist and not considered for orders in the future. 

Technology Development The e-shop requires technology-related activities in the 
enterprise because A4Y runs an application server for the e-shop platform and the 
server is protected by a firewall. The application server contains the dynamic 
webpages of the e-shop. The product search function of the e-shop platform is 
based on product data in a MySQL database. The product data are on the same 
server as the customer data. This server also has a firewall in order to provide 
protection from hacker attacks and unauthorized data access, i.e., A4Y’s employees 
do not have access to product data without an explicit permission. 

Furthermore, the branch office has a point-of-sales (POS) terminal. The POS 
terminal registers all sales of products in branch office and e-shop. The customer 
has to login to the POS terminal before he/she can place an order in the e-shop. The 
successful login is a precondition for the purchasing via the e-shop. Based on the 
customer login, a customer profile can be created which is useful for the marketing 
department because it can design the newsletter and e-mails with special offers 
targeted to the customer’s profile. The customer profile contains information 
concerning the customer’s name, address, and preferred payment methods. Sales 
of standard products without engraving can be done in the branch office without a 
login of the customer at the POS terminal. This kind of sales is registered as a 
purchase by an “anonymous customer.” Monthly statistics about the most wanted 
products of the month and the mode of purchase can be generated with the help of 
the POS terminal. These statistics are required for the long-term pricing policy and 
the accounting of the general management. 

A mobile data collection (MDC) device is used to collect information about the 
current stock. The aim is to continuously have up-to-date information about the 
number and kind of standards products and working funds. This device is out of 
date and should be replaced. During operations, the device often causes error 
messages and crashes. It also has a too small internal memory. 

The general management decided that part of the information system of A4Y 
should be outsourced. The outsourcing plans concern the MySQL database and the 
e-shop system, both of which shall be outsourced to an external cloud provider. The 
management expects that this outsourcing will reduce costs for operations and the 
technical components of the information system. 

Human Resources A4Y currently has nine employees. Two employees are work- 
ing in the IT department, two in the branch office, two in the marketing department, 
two in the manufacturing unit (a goldsmith and a foreman), and one is the general 
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manager (Mister Alexander Muller). The foreman receives the incoming goods, 
supervises the manufacturing process, reports defects to the general manager, and 
delivers the sold products with the company car to the shipping service provider. 

Due to the increasing number of orders in the Holiday season, A4Y usually hires 
additional employees with a fixed-term contract for this period. There are no rules 
or standard procedures for hiring new personnel. In case of vacancies, the general 
management is responsible and will assess the specialist knowledge as well as the 
social skills of the applicants. 

General Management The activities of the general management consist of plan- 
ning, financing, controlling, quality control, and external accounting. The general 
manager has the only responsibility for these activities. The strategic goal defined 
by the general manager for A4Y is to establish the enterprise on the Chinese market 
by opening a branch office in China during this year. 




Chapter 7 

Overview of the 4EM Method 



This chapter begins the description of the 4EM method by first providing an 
introduction to the essential features and principles that will be examined in greater 
depth in Chaps. 8 and 9. “4EM” is an abbreviation of “For Enterprise Modeling.” 
The origin of the method will be explained in more detail in Sect. 7.5. 

The remaining sections of this chapter present the method’s basic components 
(Sect. 7.1), describe the view concept used in 4EM and the associated sub-models 
(Sect. 7.2), outline the applications and benefits of 4EM (Sect. 7.3), and account for 
the participatory nature of the method (Sect. 7.4). 



7.1 Basic Components of 4EM 

The 4EM method is comprised of three core elements, which can also be regarded 
as basic principles and are closely interwoven: 

• A defined procedure to modeling using a fixed notation (defined procedure and 
notation) 

• Performance of Enterprise Modeling in the form of a project with predetermined 
roles (project organization and roles) 

• A participatory process to involve enterprise stakeholders and domain experts 
(stakeholder participation) 

These three basic elements of 4EM are supported by appropriate tools and 
resources, which is illustrated in Fig. 7.1. 

The procedure and notation are explained in detail in Chap. 8 using the case 
study presented in Chap. 6. An important principle of the 4EM approach is its 
modular structure, providing a self-contained, clearly defined procedure for each 
different aspect of Enterprise Modeling. However, how these different method 
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Fig. 7.1 Basic elements of the 4EM — framework 

components are combined can be decided based on the problem to be solved. This 
flexible method structure, which can be adapted as required, thus corresponds to the 
basic concept of method components as described in Sect. 3.2. The individual 
components of the method and their respective notations define views or 
sub-models. Section 7.2 below explains the differences between them. 

Project organization and roles are addressed in Chap. 9, where the 4EM principle 
of organizing Enterprise Modeling as a project becomes apparent. From a 4EM 
perspective, it is not enough to merely define the procedure and notation as these 
do not provide a clear description of the purpose and content, or an allocation of 
resources, or a definition of the decision-making and process structures. Understand- 
ing Enterprise Modeling as a project with a clear goal, time frame, and resources 
facilitates practical implementation and helps to achieve the specified purpose. 

Stakeholder participation is another principle of 4EM that is reflected in both the 
procedure and notation and the project structure and roles. Opportunities for 
involving domain experts and stakeholders, such as moderated workshops or 
participatory modeling, have already been covered extensively among the analysis 
techniques presented in Chap. 4. This principle will also become apparent when 
discussing roles within the project structure. 

In principle, all of the tools and tool categories discussed in Chap. 5 are viable as 
supporting tools. However, the modeling instructions and incorporated checklists 
for each 4EM sub-model in Chap. 8 also fall into this category. Table 7.1 shows the 
sections in which the individual elements of 4EM are discussed. 

The instructions and working guidelines also create an organizational frame- 
work for all persons involved in modeling, problem solving, and knowledge 
sharing, because they not only define the meaning of the symbols, colors, formu- 
lations, etc. to be used, but also indirectly define the interaction process. This aims 
to increase the productivity of the activities by preventing misunderstandings and 
conflicts. 
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Table 7.1 4EM method — sections describing the core elements 



4EM core elements 


Discussed in section? 


Procedure and notation 


7.3: Overview to sub-models 

8: Procedure and notation for every sub-model 


Project structure and roles 


9.1: project structure 
9.3: roles 


Stakeholder participation 


4: analysis techniques including participation 
9.4: roles 


Tools and aids 


5 : modeling tools 
8. 1-8.6: Modeling support 



7.2 Views and Sub-Models 



The 4EM method uses six interrelated sub-models (Fig. 7.2), which complement 
each other and capture different views of the enterprise which can also be consid- 
ered as perspectives, i.e., each of the sub-models represents some aspect of the 
enterprise. These sub-models and issues they address are: 

• Goals Model (GM) focuses on describing the goals of the enterprise. Here we 
describe what the enterprise and its employees want to achieve, or to avoid, and 
when. Goals Models usually clarify questions, such as: where should the orga- 
nization be moving, what are the goals of the organization, what are the 
importance, criticality, and priorities of these goals, how are goals related to 
each other, which problems are hindering achievement of goals. 

• Business Rule Model (BRM) is used to define and maintain explicitly formulated 
business rules, consistent with the Goals Model. Business Rules may be seen as 
operationalization or limits of goals. 

Business Rule Model usually clarifies questions, such as: which rules affect 
the organization’s goals, are there any policies stated, how is a business rule 
related to a goal, how can goals be supported by rules. 

• Concepts Model (CM) is used to strictly define the “things” and “phenomena” 
one is talking about in the other models. We represent enterprise concepts, 
attributes, and relationships. Concepts are used to define more strictly expres- 
sions in the Goals Model as well as the content of information sets in the 
Business Processes Model. 

Concepts Model usually clarifies questions, such as: what concepts are rec- 
ognized in the enterprise (including their relationships to goals, activities and 
processes, and actors), how are they defined, what business rules and constraints 
monitor these objects and concepts. 

• Business Processes Model (BPM) is used to define enterprise processes, the way 
they interact and the way they handle information as well as material. A business 
process is assumed to consume input in terms of information and/or material and 
produce output of information and/or material. In general, the BPM is similar to 
what is used in traditional data-flow diagram models. 
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Fig. 7.2 Sub-models of the 4EM approach and their relationships 



Business Process Model usually clarifies questions, such as: which business 
activities and processes are recognized in the organization, or should be there, to 
manage the organization in agreement with its goals? How should the business 
processes, tasks, etc. be performed (workflows, state transitions, or process 
models)? Which are their information needs? 

• Actors and Resources Model (ARM) is used to describe how different actors and 
resources are related to each other and how they are related to components of the 
Goals Model, and to components of the Business Processes Model. For instance, 
an actor may be the responsible for a particular process in the BPM or the actor 
may pursue a particular goal in the GM. 

Actors and Resources Model usually clarifies questions, such as: who 
is/should be performing which processes and tasks, how is the reporting and 
responsibility structure between actors defined? 

• Technical Components and Requirements Model (TCRM) becomes relevant 
when the purpose of 4EM is to aid in defining requirements for the development 
of an information system. Attention is focused on the technical system that is 
needed to support the goals, processes, and actors of the enterprise. Initially one 
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needs to develop a set of high-level requirements or goals, for the information 
system as a whole. Based on these, we attempt to structure the information 
system in a number of subsystems, or technical components. TCRM is an initial 
attempt to define the overall structure and properties of the information system to 
support the business activities, as defined in the BPM. Furthermore, the TCRM 
can be used to document the existing information system and IT landscape in an 
enterprise. 

The Technical Components and Requirements Model usually clarifies ques- 
tions, such as: what are the requirements for the information system to be 
developed, which requirements are generated by the business processes, which 
information systems and IT-components are used in the enterprise in what 
business process by what actor, which potential has emerging information and 
communication technology for process improvement. 

Each of these sub-models includes a number of components describing different 
aspects of the enterprise. For example, the Goals Model contains business goals, 
business problems, divided into threats and weaknesses, causes, business opportu- 
nities, and constraints. The modeling components of the sub-models are related 
between themselves within a sub-model (intra-model relationships), as well as with 
components of other sub-models (inter-model relationships). 

Figure 7.2 shows inter-model relationships. The ability to trace decisions, 
components, and other aspects throughout the enterprise is dependent on the use 
and understanding of these relationships. When developing a full enterprise model, 
these relationships between components of the different sub-models play an essen- 
tial role. For instance, statements in the Goals Model allow different concepts to be 
defined more clearly in the Concepts Model. A link is then specified between the 
corresponding Goals Model component and the concepts in the Concepts Model. In 
the same way, goals in the Goals Model motivate particular processes in the 
Business Processes Model. The processes are needed to achieve the goals stated. 
A link therefore is defined between a goal and the process. Links between models 
make the model traceable. They show, for instance, why certain processes and 
information system requirements have been introduced. 

There exist, however, limitations in the way sub-models and their relationships 
may be populated. These are controlled by a number of static as well as dynamic 
consistency rules, which control their permissible state transitions. These are 
necessary because they allow for analysis and comparison. How each sub-model 
focuses on a specific view of the enterprise will be described in detail in the 
following chapter. 
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7.3 Application Areas and Results 

The 4EM method describes an approach that allows an enterprise or section of an 
enterprise, along with its structures and processes, to be analyzed, researched, and 
documented in the form of models. A number of applications for the 4EM method 
have already been described in Chap. 2, which discussed the practical challenges 
that can be addressed with EM methods. Regardless of these practical challenges, 
4EM can generally be used when information and a model regarding the following 
aspects are required: 

• How does the enterprise work at present? 

• Where do problems or challenges exist that necessitate changes in the 
enterprise? 

• What are the requirements for these changes? 

• What are the options for meeting these requirements? 

• What criteria and arguments can be used to evaluate these options? 

When using the 4EM method, a wide variety of enterprise stakeholders (such as 
executives, organizational unit managers, staff from specialist departments, or 
domain experts) are often involved, working on the designated task with experts 
in the 4EM method and the analysis techniques used. The organization of this 
teamwork in project form is addressed in Chap. 9. In most modeling projects there 
are three activities to be carried out, which provide answers to the questions listed 
above: 

1. Analyzing : First, the current situation in the enterprise is modeled (AS-IS model) 
and the discernible problems and weak points are identified. Only those who 
know the current situation can plan for the future. 

2. Assessing : Possible courses of action must be discussed and assessed in light of 
the actual situation with its problems and weak points, as well as the enterprise’s 
current goals and the challenges posed by the market environment. In this 
assessment phase, it is also very important to reveal and understand goal 
conflicts and priorities as well as their effects on structures and processes. 

3. Designing : Finally, various future scenarios are investigated and the future 
situation to be achieved in the enterprise is devised and modeled (TO-BE 
model). The target situation then serves as a blueprint or specification for the 
changes to be made, which may be purely organizational in nature or include the 
implementation or revision of IT-based solutions. 

The enterprise models produced in the process above (AS-IS and TO-BE) should 
enable the enterprise to make well-founded and purposeful tactical and strategic 
decisions (Fig. 7.3). 

This three-stage process uses a number of the sub-models introduced in Chap. 8, 
each representing different views in terms of their content. One view might be 
business processes, for example, or the information systems that support these 
processes. The goal model is normally one of the sub-models with a bearing on 



7.3 Application Areas and Results 



81 



Current Situation 

„As-ls" 



Enterprise 

Model 



Modelling the 
Enterprise 




Analyse 



The Need 
for Changes 




Consider 
transition and 
alternatives 




Evaluate 



Fig. 7.3 Essential tasks of the 4EM process 
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all three phases of the process, and allows an enterprise’s goals to be identified and 
described. This sub-model is certainly necessary in the assessment stage (What 
should be achieved? What goals have priority?), and often can also be helpful 
during the analysis phase (What are the analysis goals? What must be considered?). 
The goal model can also be used as a rationale when designing the future situation. 
The various enterprise goals can be linked together in the goal model, thus 
depicting the goal hierarchy in the enterprise. If, for example, an enterprise defines 
“optimize production process” as a sub-goal, this could be associated with the 
overarching goal “increase profits by 20 Goal conflicts may arise here; for 
example, the latter goal has a negative effect on other goals, such as “reduce 
operational costs by 10 %”, as a software rollout that is required to optimize the 
production process incurs implementation costs and thus reduces profits. The 
relationships between individual sub-models and their views are also relevant to 
all three phases. In the example cited, the goal “optimize production process” could 
refer directly to the process to be optimized and to the stakeholders responsible, 
which are modeled in a business process model and an actor and resource model. 
Enterprise models and their related sub-models are discussed in detail in Chap. 8. 

The 4EM method provides conceptual models that examine an enterprise and its 
requirements from a number of perspectives with varying connections. These 
models and their dependencies are an abstraction of the real-life situation in the 
enterprise and constitute the enterprise model. 

In addition, the resulting models can be combined with information that allows 
alternative operational situations to be evaluated, for example. This information 
might include evaluation criteria, potential choices, measurements, and the pros and 
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cons of the available options. This makes it possible for the model to be used as a 
means of evaluating changes, for instance allowing the costs of different variations 
to be analyzed while simultaneously documenting their effects on the organization. 

In this regard, the enterprise model can aid understanding and communication 
between project participants or the various stakeholders in the 4EM process during 
every stage of development. The model effectively creates a common frame of 
reference across many different divisions and processes, with the result that its use 
is not limited to specific applications or particular groups. Amongst other things, the 
4EM model’s wide range of potential applications and high level of abstraction 
ensure that the target models remain valid for a relatively long period of time, as 
they are not dependent on the implementation method. Changes to the target model 
are only necessary when required by the enterprise’s objectives or activities, rather 
than in the event of changes to the technological implementation. 



7.4 Effects of the Participatory Approach 



One of the principles of the 4EM method is for enterprise stakeholders to participate 
in Enterprise Modeling. Due to the participatory approach, the outcome of a 
modeling project not only includes the models that are developed and the decisions 
or changes made in the enterprise, but also results in participants having a better 
understanding of the problem solving process, and often even of their own 
enterprise. 

The developers of 4EM chose participatory cooperation with stakeholders as a 
result of their practical experience in Enterprise Modeling. They recognized that 
agreements can be reached and problems solved much more effectively when 
stakeholders, instead of feeling “affected” by Enterprise Modeling, become active 
“participants.” In 4EM’s participatory approach, the stakeholders — under the guid- 
ance of a moderator and with the help of modeling experts — create models to solve 
the previously defined problem in appropriate modeling workshops. The moderator 
and modeling experts ensure that the domain experts and the stakeholders involved 
can focus completely on solving the problem, without the need to leam the syntax 
of a modeling language first. Once the model is created, the domain experts are 
consulted to discuss and validate the models created by modelers, but are directly 
involved in actually developing the model. 

Not every modeling workshop will produce a high-quality model. However, the 
meetings almost always add value because the 4EM process always produces two 
results. Firstly, regardless of their state of development, the models that are created 
can always be used as a basis for other activities, whether as a starting point for 
discussion in further modeling workshops or to capture facts that were previously 
only available in the heads of individual employees. Secondly, the 4EM method 
changes the approach to problem solving processes as the participants are guided 
through a structured and consensus-based process. 




7.4 Effects of the Participatory Approach 



83 



There are two major advantages attributed to this approach: 

1. The participatory approach involves stakeholders in the decision-making and 
problem solving process, which increases the participants’ acceptance and 
commitment. This is particularly important if the modeling activities concern 
changes to organizational units, fields of work, visions and strategies, business 
processes, or information systems. 

2. In the conventional approach to Enterprise Modeling, models are often created 
by consultants or modeling experts based on interviews, observation, or work- 
shops, with no participation by those involved in the enterprise. By contrast, the 
participatory approach improves model quality as the models are created in 
cooperation with domain experts and the parties concerned, and are constantly 
reviewed and validated. 

Model quality can be understood to mean correctness and consistency with 
respect to the notation, or may also concern the model’s relevance in solving the 
given problem. Models that help to solve the specified problem when used as a 
whole are considered to be high quality. The results of the 4EM method are 
typically used in information system or process development projects. High-quality 
models may: 

• Provide a clear business overview 

• Support organizational learning 

• Help to understand an enterprise’s capabilities and processes 

• Improve communication between the individual stakeholders about a problem 
that is to be solved through a modeling project 

• Form a rationale for analysis tasks with the help of structured views and 
descriptions 

• Easily extrapolate requirements for process-supporting information systems 

• Present a consistent and more comprehensive model by systematically describ- 
ing business goals, processes, requirements, etc., which is difficult with tradi- 
tional text-based approaches 

• Contribute to continuous improvements in the quality of enterprise processes 
and structures 

Modeling experts also cite a changed attitude to the problem solving process and 
enhanced internal knowledge of the organization as the most important reasons for 
satisfaction with the outcome of a modeling project using the participatory 4EM 
approach. The stakeholders in a modeling project have different and sometimes 
contradictory success criteria, which must be appropriately investigated during 
project preparation. Ultimately, the most important gauge of a project’s success is 
that the customer is satisfied with the result, a sign of which is commissioning 
follow-up projects to tackle further challenges. Moreover, the source of the partic- 
ipating stakeholders’ satisfaction and motivation is the fact that they work together 
in the organization to solve a problem, which can be beneficial for every individual. 
This motivation is particularly important because improvement and the associated 
change is a continuous process that can be supported by the 4EM method. The 4EM 
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method uses simple techniques to capture more complex facts, and is therefore 
highly suitable as a basis for representation and discussion. Consequently, a prop- 
erly conducted modeling project can provide the following benefits for those 
involved: 

• Better understanding of the relevant parts of the enterprise and how they 
interrelate 

• Problem solving decisions made by the parties concerned 

• A model as a rationale 

• Collective discussion of critical issues to find a solution together 

• Enhanced organizational learning and communication 



7.5 Origin of 4EM 



The 4EM Method as such is only a few years old, but result of a continuous 
improvement process of its predecessor EKD (see below) and other preceding 
methods. 

In Scandinavia, Langefors (1968) made early contributions to EM. An EM 
method, the ABC method, was introduced in the beginning of the 1980s by 
Plandata, Sweden (Willars 1988), and refined by SISU (The Swedish Institute for 
System Development) in the late 1980s. A significant contribution of this strand of 
EM was the notion of considering intentional components of an Enterprise Model- 
ing language, e.g., the goals (intentions) of a business, in addition to traditional data 
and process model components. SISU’s version of the modeling language, denoted 
Business Modeling , was later extended into an Enterprise Modeling method in the 
ESPRIT project F 3 — “From Fuzzy to Formal.” The F 3 Enterprise Modeling method 
(F 3 1994) was then further elaborated in the ESPRIT project ELKD. The more 
recent modeling method is denoted EKD — “Enterprise Knowledge Development” 
(Bubenko et al. 2001; Loucopoulos et al. 1997). 

The EKD method defines a structured approach for capturing different aspects of 
an enterprise in appropriate sub-models. EKD forms the main foundation for the 
4EM method. The history of different Enterprise Modeling methods and of 4EM is 
depicted in Fig. 7.4. 

Versions of EM methods from this “school” have been successfully applied in a 
number of European companies, e.g, British Aerospace (UK), Capital Bank (UK), 
National Bank of Greece, PostGirot (Sweden), Public Power Corporation (Greece), 
Serna Group (France), Telia (Sweden), Vattenfall (Sweden), Volvo (Sweden), etc. 
In addition to the “Scandinavian” school of EM, a variety of other methods have 
been suggested (See e.g. Bajec and Krisper 2005; Castro et al. 2001; Dobson 
et al. 1994; Fox et al. 1993; Yu and Mylopoulos 1994; Zorgios 1994). 

The application projects have shown that one of the main advantages of the 
method is its acceptance by the participants in the modeling project, i.e., not only is 
it accepted by the modelers but also by domain experts and other participants. 
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4 Enterprise Modelling 



2010 



2000 



Enterprise Knowledge Development 



1990 



1980 



1970 



1960 

Fig. 7.4 




Data Modelling 




Participative Development 






BSP 




Goal Analysis & IS Analysis (Langefors) 



DFD 



History of the 4EM method 



This better acceptance resulted in a better quality of the models developed, in an 
improved understanding of the enterprise, in an easier way to identify operative and 
strategic problems, and a faster problem solving process. 

Table 7.2 shows a selection of projects, where EKD or 4EM were used for 
different modeling purposes. 

In addition to the projects listed 4EM has frequently been used in university 
education. Currently, 4EM is part of university courses on Bachelor and Master 
level in Stockholm (Sweden), Riga (Latvia), Jonkoping (Sweden), Skovde (Swe- 
den), and Rostock (Germany). 

When preparing this book, the EKD version published in 1998 was thoroughly 
revised and extended, which resulted in the 4 Enterprise Modeling (4EM) method. 
This revision included improvements in the notation (e.g., use of colors, modifica- 
tions in the symbol used, adjustments in the meta-model), refinements of the 
modeling procedure and the project approach, and more detailed information 
regarding the foundations of methods and elicitation techniques. 
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Table 7.2 Overview to 4EM application cases 



Organization 


Application domain 


Time 

frame 


Project focus 


British Aerospace, 
UK 


Production and opera- 
tions in aerospace 


1992- 

1994 


Requirements analysis 


Telia AB, Sweden 


T elecommunication 


1996 


Requirements elicitation, definition 
of project scope 


Volvo Cars AB, 
Sweden 


Automotive industry 


1994- 

1997 


Requirements analysis 


Vattenfall AB, 
Sweden 


Electricity supplier 


1996- 

1999 


Change Management 
Process management 
Competence Management 


Riga Dity Council, 
Latvia 


Public authority 


2001- 

2003 


Supportive process for knowledge 
management 


Verbundplan 
GmbH, Austria 


Electronics industries 


2001- 

2003 


Knowledge managemenz processes 


Skaraborgs Hospi- 
tal, Sweden 


Healthcare 


2006- 

2008 


Strategy development; knowledge 
management processes 


Systeam Manage- 
ment, Schweden 


Software industries 


2009 


Strategy development 


Future TV, 
Germany 


Media industries 


2011- 

2012 


Alignment of IT strategy and busi- 
ness processes/IT 


DRK, Germany 


Social services 


2012- 

2013 


Development and implementation of 
an organizational strategy 





Chapter 8 

Sub-models of 4EM 



This chapter presents the sub-models of the 4EM language as well as the basic 
principles of using them. The details of setting up a modeling project and carrying 
out the modeling process are discussed in Chap. 9. Furthermore, in Chap. 12 the 
main quality criteria for models are described. The sub-models presented in this 
chapter are the Goals Model, the Business Rules Model, the Concepts Model, the 
Business Process Model, the Actors and Resources Model, the Technical Compo- 
nents and Requirements Model, as well as the use of inter-model links that connect 
the sub-models. As a running example we will use A4Y case described in Chap. 6. 

The main focus of this chapter is on the modeling language — meaning and 
purpose of the modeling components and the sub-models. The graphical look of 
the modeling components is usually influenced by the modeling tools used and can 
in principle be changed without affecting the outcome of modeling. There are 
however some general principles that should be followed — every modeling com- 
ponent should have a unique identifier including the type of modeling component 
and the graphical symbol should be well readable both on the screen and when 
printed. Recommended template of 4EM is shown in Fig. 8.1. Sometimes the 
combination of identifier and number is referred to as short name of the component. 



8.1 Goals Model 

The Goals Model is used for describing the goals of the enterprise along with the 
issues associated with achieving these goals. The Goals Model describes essentially 
the reason, or motivation, for components in the other sub-models. The components 
of this model are related to the enterprise itself and its rationale. Information system 
goals and requirements should not be stated here. The Goals Model forms the 
framework with which the relevance of processes and technical system require- 
ments are measured and to which they are linked. Through links to and from the 
other sub-models, the Goals Model explains why, or why not, processes and 

© Springer-Verlag Berlin Heidelberg 2014 87 

K. Sandkuhl et al., Enterprise Modeling , The Enterprise Engineering Series, 

DOI 10.1007/978-3-662-43725-4_8 



88 



8 Sub-models of 4EM 



Fig. 8.1 Template of 4EM 
components 



<ldentifier><Number>(+) 
<Component Text> 



requirements exist or do not exist. The components of the Goals Model are related 
to each other through unidirectional semantic links of which the three main types 
are supports, hinders, and conflicts. 



8.1.1 Components of the Goals Model 

Component types of the Goals Model are the following: goal, problem, cause, 
constraint, opportunity. However, observations from a number of practical model- 
ing sessions show that sometimes it is necessary to add additional components to 
the model, such as comments, assumptions, scenarios, tasks, etc. The purpose of 
such extensions is usually to improve the expressiveness and clarity of the model. 



8.1. 1.1 Goal 

A business Goal is a desired state of the enterprise that is to be attained. It is used for 
expressing goals regarding the business or state of business affairs, i.e., what the 
enterprise and its employees want to achieve, or to avoid, and when. 

Goals may be expressed as a measurable set of states, or as general aims, visions, 
or directions. Goals can be several meanings, such as business goals, objectives, 
intentions, needs, business requirements, desired states, etc. Intentional sentences 
should begin with the phrase “The goal is . . .”. This phrase can be omitted but the 
expression should be such that if added it would still remain grammatically and 
logically correct. Figure 8.2 shows an ambiguously formulated goal on the left 
while the goal on the right is more precisely formulated. 

It is recommended to follow the principle of SMART goals, meaning that every 
goal should be specific (S), measurable (M), accepted (A), realistic (R), and time 

Ambiguous More precise 

goal formulation goal formulation 







Goal 1 


Goal 1 




Increase in profits of the 


Make more money 




enterprise by 15% during this 






year 



Fig. 8.2 Formulation of the goal statements 
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framed (T). This guideline contributes to increasing the understandability and 
usability of the model. In Fig. 8.2 the goal on the right follows this principle. 

Goals may also have the optional variables priority and criticality (with possible 
values: low, medium, high), which allow modelers to assign different priority levels 
and perceived degree of criticality. 

Goals modeling requires the participants to reflect over, and state their short as 
well as long-range goals about the enterprise. It also requires the modeling partic- 
ipants to discuss and agree upon issues such as the individual importance of goals, 
the criticality of goals, and the priority of goals, as well as evaluating alternative 
ways of achieving goals. These issues should not necessarily be discussed at once. It 
is more useful that the modeling group returns to them during the course of the 
modeling workshop. 



8.1. 1.2 Problem 

A Problem is used for expressing that the environment is in, or may reach, some 
non-desirable state of affairs that needs to be addressed, which hinders the achieve- 
ment of goals. By documenting perceived problems, a basis is created for detecting 
hidden goals that may otherwise only be implied, because problems typically hinder 
the achievement of some goal. If a stated problem cannot be seen as hindering some 
goal, then either the set of goals is incomplete or the problem really is not a problem 
of the enterprise. 

Problems may be specified into two subtypes: 

• Weaknesses — a type of problem describing factors that may reduce the possi- 
bility of achieving a goal. Weaknesses typically are factors that can be consid- 
ered as internal with respect to the problem domain. 

• Threats — a type of problem describing influencing forces that may reduce the 
possibility of achieving a goal. Threats typically are external factors coming 
from outside of the problem domain. 

Figure 8.3 shows examples of problems. 



Problem 3 




Weakness 3 




Threat 5 


Missing success monitoring of 




The blacksmith is not qualified 




The change of regulation 


Offline marketing operations 




to handle maintenance work of 




enforces the ISO standard 






The machines 




2206 from next year 



Fig. 8.3 Problem, weakness, and threat 
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8.1.1.3 Cause 

A Cause is used for expressing the explanations or reasons for Problems. Causes are 
usually situations or states, outside the control of the project, process, and organi- 
zation. It may be something that is well understood and does not need to be 
analyzed further. Typically, a cause cannot be affected by the enterprise. An 
example is given in Fig. 8.4. 



8.1.1.4 Constraint 

A constraint is used for expressing business restrictions, rules, laws, or policies 
from the outside world affecting components and links within the enterprise model. 
Internal business rules and policies of the organization are defined in the Business 
Rules Model. Figure 8.5 provides an example. 



8.1. 1.5 Opportunity 

An opportunity is used for expressing resources that can make certain goals easier 
to achieve, achievable states not regarded as Goals, or even to state new goals of the 
enterprise. For instance, new communication technology may facilitate an enter- 
prise’s possibilities to achieve a goal to enlarge the international market of its 
products. Opportunities are situations that we may want to take advantage of and 
consider for development (see Fig. 8.6 for an example). If so, the Opportunity 
should be transformed into a Goal at a later modeling stage. 



Problem 3 




Cause 1 


Missing success monitoring of 


4 - causes — 


The total amount of marketing the 


Offline marketing operations 


company operations drew customers 
attention to 



Fig. 8.4 A cause linked to a problem 



Goal 3.5 




Constraint 1 


Decrease the recruitment of 


4 — hinders 


The existence of statuatory 


temporary workers at peak times 




regulations for maximum overtime 



Fig. 8.5 A constraint hindering a goal 






8.1 Goals Model 



91 



Goal 3.1 
Reduce the maintenance - 
costs of machines 



supports 



Opportunity 10 
Outsource maintenance to 
external maintenance 
supplier 



Fig. 8.6 Opportunity supporting a goal 



Goal 3(+) 

Cut the costs by 10 % 


-^-supports — 


Goal 4(+) 

Optimize the manufacturing 
processes 








Goal 6.1 

Create a more transparent 
marketing budget allocation 


hinders — 


Problem 3 

Missing success monitoring 
of offline marketing 
operations 








Goal 2(+) 

Increase the sales with the 
assistance of promotional 
measures 


— hinders — ► 


Goal 3(+) 

Cut the costs by 10 % 



Fig. 8.7 Examples of binary relationship types in Goals Model 

8.1.1.6 Links Within the Goals Model 

The link types between the components of the Goals Model are (Fig. 8.7): 

• Supports relationship, that is used to show that fulfilling one goal supports 
fulfilling another. Supports is essentially seen as “vertical” relationship, i.e., it 
is used to refine or decompose goals into other often more operational goals. 

• Hinders relationship, that is used to show negative influences between compo- 
nents of the Goals Model, and can be considered as opposite to “supports.” 

• Conflicts relationship, that is used in a situation when an achievement of a goal is 
in conflict with another. 

Initially the Goals Model may have a high level of abstraction. To obtain more 
clarity and to specify goals in more detail it is often necessary to decompose or to 
refine them to sub-goals. Such possibilities are provided by AND, OR , as well as 
AND/OR relationships. 

The AND refinement relationship is used to specify a set of unique sub-goals that 
are necessary to satisfy a goal (Fig. 8.8). 

The OR refinement relationship is used to specify a set of alternative sub-goals 
that support a goal. It is sufficient to satisfy only one goal from the set (Fig. 8.9). 

The AND/OR relationship is used to specify a set of alternative sub-goals — to 
support a goal. A combination of sub-goals from the set will satisfy a goal (Fig. 8.10). 
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Fig. 8.8 Example of goal refinement with AND relationship 




Fig. 8.9 Example of goal refinement with OR relationship 




Fig. 8.10 Example of goal refinement with AND/OR relationship 
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8.1.2 Notation 

The notation of the Goals model is depicted in Fig. 8.11. 




Fig. 8.11 Notation of Goals Models 

8.1.3 Example Goals Model 

8.1.3.1 Modeling the Current Situation (the AS-IS Model) 

A4Y’s primary objective for the current year is to reach a profit increase of 15 % 
(Goal 1). There are two sub-goals that support the achievement of this primary 
objective. The company can increase its profits by increasing its sales through 
promotional measures (Goal 2), by lowering its operating costs by 10 % (Goal 3), 
or by implementing a combination of Goal 2 and 3 (Fig. 8.12). 
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Fig. 8.12 Top goals of A4Y 



Goal 5(+) 
Increase acquisition of 
new customers 



supports" 



Goal 2 

Increase sales by using 
promotional measures 



Goal 3(+) 

Reduce operating costs by 10% 




Goal 2.1 




Goal 2.2 




Goal 2.3 


Develop both new 




Decrease the time 




Extend the range of 


products variants and 




to market 




services 


versions 











hinders 



supports 

A 



supports 

A 



supports 

L 



The development of 




Goal 10 




Goal 1 1 




Opportunity 9 


new products is cost- 




Investigate the acquisition of 




Implement third 


< supports- 


The implementation 


intensive as well as 




more efficient and higher quality 




party payment 


of PayPal 


time consuming 




machines 




services 







Fig. 8.13 Further refinement of goal 2 by defining sub-goals and exploring opportunities 



In order to increase sales, the company A4Y can acquire new customers (Goal 5) 
or expand its marketing activities (Goal 6). Both goals support Goal 2. Further 
refinement of Goal 2 can be done by introducing more sub-goals: development of 
new product versions/variants (Goal 2.1), reducing the time to market (Goal 2.2) or 
extension of services (Goal 2.3). As these goals belong to Goal 2 they can be seen as 
refinement of this goal. Therefore, Goal 2 is marked in the top-level model with a 
(+) to indicate the existence of a decomposition (see Fig. 8.12). This decomposition 
with the sub-goals included is illustrated in Fig. 8.13. In order to reach these goals, 
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the company already investigated potential measures, such as the introduction of a 
new payment system (Opportunity 9). 

However, the achievement of Goal 2.1 is also associated with the problem that 
development of new products is time-consuming and is associated with substantial 
costs (Problem 9). This problem has an indirect effect on Goal 3, as it is in conflict 
with the reduction of operational costs (see Fig. 8.13). To resolve this conflict, the 
company has to decide how to deal with this issue in the future. The decision should 
be documented in the final version of the model. After further analysis of the 
sub-goals of Goal 2, Goal 10 is introduced, which defines the need to investigate 
the possibility to acquire more efficient machinery, as well as Goal 1 1 that identifies 
the need to implement third-party payment services. Opportunity 9 documents one 
such option — to use PayPal services. At this stage this is modeled as an opportunity 
because the company has not yet decided which supplier to use for these services. 

In order to increase the profit of the company according to defined goals, 
operational costs should be reduced in addition to increasing sales. This objective 
is modeled with Goal 3, which in turn consists of several sub-goals. On the one 
hand, Goal 3 consists of the sub-goal of optimizing production processes (Goal 4 in 
Fig. 8.12) and on the other hand it consists of several supporting sub-goals (see 
Fig. 8.14). Thus, Goal 3 is also marked with a (+). There are also weaknesses, 
threats, and restrictions influencing the goals (see Fig. 8.14). For Goal 3.2, the 
company has documented a weakness that the shipping guidelines so far have not 
been applied in a satisfactory way. Therefore, this weakness hinders Goal 3.2. 
Another problem that hinders Goal 3.1 is the risk that the blacksmith does not have 
the necessary knowledge for maintenance of the machinery. Both problems 




Fig. 8.14 Refinement of goal 3 
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(Weakness 5 and Threat 6) can be solved by simple measures. Nevertheless, there is 
a restriction, which cannot be influenced by the company and which hinders the 
achievement of Goal 3.3 — in periods with high workload, the company either hires 
additional workers for a limited period of time or the regular employees work 
overtime. In both cases the length of temporary employment and the maximum 
overtime of regular employees is strictly regulated by law (Constraint 1). 



8.1.3.2 Modeling the Company’s Vision (the TO-BE Model) 

A4Y decided not to invest in new machinery for developing new products and 
product variants in the near future. Based on this decision, an agreement is reached 
on how to solve the conflict between Goals 2 and 3. The agreement is to increase 
sales through promotional activities to a certain degree, and to put the main focus on 
reduction of operating costs. 

Accordingly, Goal 2.1 and the associated Problem 9 were removed, because it 
was assumed that the high costs associated to this goal could hinder Goal 3 (see 
Fig. 8.15) which is not acceptable. 

So far the model of the future state (TO-BE model) has been developed by 
simplifying and removing modeling components. This, of course, is not the only 




Fig. 8.15 Future state goals for Accessories4you (TO-BE Goal Model) 
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Fig. 8.16 Goal refinement in the TO-BE Goal model 



Goal 6 

Expand marketing 
activities 



supports 

Z 


\ 

supports 
\ 






Goal 6.2 

Use up to 10% of the 
last year’s turnover for 
marketing operations 




Goal 6.1 
Create a more 
transparent marketing 
budget allocation 


4— hinders — 


Problem 3 
Missing success 
monitoring of offline 
marketing operations 




/ \ 

supports supports 

/ \ 







Goal 14 

Introduce a central 




Goal 15 


system for budget 
planning 




Introduce analysis 
tools 



Fig. 8.17 Further goal refinement in the TO-BE model 



way — there also is a need to develop the model by introducing new components 
that support the main objective of the company. For example, Goal 6 and Goal 4 are 
extended with new sub-goals (Goal 6.2, Goal 4.1, Goal 4.2, Goal 4.3) as shown in 
Figs. 8.16 and 8.17. 



8.1.4 Developing and Refining the Goals Model 



In the previous section we showed a small example of goal modeling for the AS -IS 
and TO-BE states of an organization. There are some common principles of 
developing a goals model in a modeling workshop, which are discussed here. 
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Developing a Goals Model is initially a brainstorming activity. Views and 
contributions from all participants must be considered, which normally makes the 
initial product of modeling unstructured and difficult to understand. Initial versions 
of Goals Models often look like islands of goals and problems where the grouping 
of modeling components implies certain categorization with respect to the model- 
ing problem. Once this is done the following steps include structuring, classifica- 
tion, and operationalization of Goals Model components. This is normally done 
collaboratively in an iterative fashion, where participating stakeholders are contin- 
uously consulted to validate the progress. Naturally, this also leads to discovering 
new goals and/or problems, which are in turn analyzed and added to the Goals 
Model that emerges as a result of the modeling effort. 

It is important, when developing a Goals Model, to concentrate on the business 
itself, and not on supporting information system and more technical goals related to 
the systems. Information systems goals will be modeled in the Technical Compo- 
nents and Requirements Model (Sect. 8.6). 

The static rules of the enterprise, as well the dynamic rules that govern the 
permissible state changes of the enterprise, are also informally defined in this 
sub-model. Normally “business rules” can be seen as refinements of higher level 
business goals or constraints. The business rules are then further elaborated in the 
Business Rules Model (Sect. 8.2). 

At any stage of goal modeling, it is useful to use, or at least to keep in mind, some 
driving questions. These will keep the modeling effort focused and moving forward. 

Table 8.1 suggests a number of driving questions for goal operationalization and 
refinement of goals. These two actions deserve a closer look. 

The purpose of the goal operationalization is to elaborate detailed measures for 
fulfilling high-level goals. Operationalization of the Goals Model encourages the 
development of a goal network, usually a hierarchy, where top-level strategic goals 
are decomposed into a number of more operational sub-goals. However, it needs to be 
pointed out that in practice categorizing goals into strategic or operational goals is not 
easy or even needed, because in the goal hierarchy there are also goals “in the middle” 
which are not as specific as operational goals and not high enough in the hierarchy to be 
called strategic. The key aspects of the goal operationalization process are: 

• Emphasis on creativity: goal operationalization reflects a creative jump from 
present facts to future possibilities that bring into being something new that has 
not previously existed. 

• Emphasis on the dynamic nature of the modeling process: the result of the 
process is not static but depends on the design decisions and the visions of the 
future situation during the operationalization process. This means that the 
outcome of the process is not always the same. 

The operationalization is characterized by two principal types of activities — 
goal refinement and conflict management. 

During goal refinement , new goals are generated from the initial high-level goals 
into detailed and clarified goals. In this sense a high-level goal is refined into one or 
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Table 8.1 Driving Questions for goal modeling 



Question 


Motivation 


What are the strategies of this part of the 
enterprise? 


Goal modeling aims to capture the organiza- 
tion’s vision and strategy. In most cases parts 
of the strategy are defined and hence need to 
be captured in the model 


Are there stated policies in the enterprise that 
may influence this model? 


New designs introduced in the model should 
be aligned with the overall legal framework of 
the business. This might concern internal as 
well as external laws, policies, and rules 


Which conventions, rules, regulations, and 
laws are relevant? 


These need to be discussed and in some cases 
modeled as constraints or even problems if 
they restrict the business. Compliance to rules 
and regulations can also be modeled as busi- 
ness goals 


What would you like to achieve? 


This aims to capture stakeholder intentions 
concerning the problem domain. Typically 
each stakeholder comes up with a few pro- 
posals that are then discussed and introduced 
in the model 


Taking a particular goal, how can we make this 
goal more specific, more relevant to our pro- 
ject! company? 


This question aims to make formulation of a 
goal more specific and measurable in order to 
arrive at a SMART goal 


Are there any particular problems hindering 
this? 


This question is linked to the above, triggering 
thinking about various obstacles to the vision 
that emerge in the model 


Is this problem related to a particular goal? 


Each stakeholder may propose a few problems 
that are then discussed and introduced in the 
model 


What is the cause of this problem? 


In some cases problem causes may need to be 
discussed and modeled 


How can this problem be eliminated? 


This question triggers thinking about potential 
solutions to problems. It might actually hap- 
pen that in the initial stages of modeling a 
Goals Model contains a large number of 
problems, but at later stages they are solved by 
formulating appropriate goals 


Are there any particular opportunities that one 
could use? 


This question is useful when finding new 
alternatives to business solutions 


What actions could be taken to improve the 
situation? 


This question usually triggers seeking for 
solutions to problems and leads to goal 
operationalization. It can also lead to 
switching to modeling business rules and/or 
business processes 


How can this goal be achieved? Can this goal 
be defined in operational terms, by identifying 
a number of supporting sub-goals? 


These are more concrete questions leading to 
defining operational sub-goals 



(continued) 
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Table 8.1 (continued) 


Question 


Motivation 


Why and How? 


Asking “why” to every goal typically extends 
the model “upwards” and allows goals 
supported by the goal being analyzed. Asking 
“how” to every goal typically extends the 
model “downwards” and helps formulating 
sub-goals that need to be fulfilled to achieve 
the goal currently being analyzed. In some 
cases the “how” question also leads to formu- 
lating business rules and/or business processes 
because these components also deal with 
implementing enterprise strategies. These two 
questions essentially are used for goal refine- 
ment and operationalization 



more sub-goals that can, in turn, be refined in sub-sub-goals. The result of these 
successive refinements is a multilevel hierarchical structure, starting from high- 
level vague enterprise objectives down to specific operational goals. In goal refine- 
ment, it is possible to use AND/OR relationships in the structures, to refine goals 
into several alternative combinations of sub-goals, or a sub-goal can be realized by 
several alternative models. 

Goal conflicts management consists of a number of activities such as the 
following: 

• Conflict detection: This focuses on identifying conflicts between goals. It may 
be difficult to relate new goals to existing goals and to determine the effect of the 
former on the latter. To do this, one should exhaustively search the goal model 
and compare the new goal to each existing goal for conflicts. A reasonable way 
to search for potential goal conflicts is to use the high-level goal conflicts that 
have already been identified during the goal acquisition stage. The heuristic rule 
is that it is more likely to find conflicts between sub-goals of previously 
identified conflicting high-level goals. 

• Conflict classification : This focuses on identifying the kind of conflict that has 
been detected. Ends conflict — Goal conflicts may occur when two contradictory 
goals are desired. Means conflict — When actors hold identical goals. However, 
these goals are in conflict because each actor wants to use the same resource. 
Conflict classifications may be used by conflict management methods to react 
accordingly. 

• Conflict handling focuses on acting in case of conflict. Alternatives are the 
following: 

- Ignore : for example, when conflict does not prevent further development. 

However, it is necessary to keep track of the conflict in case its impact 



increases. 
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- Ameliorate: the balancing of conflicting goals may not be clear until the 
various design possibilities are explored in terms of alternatives. This way the 
decision is shifted to the model generation stage, when more concrete data 
about a situation is available. 

- Resolve the conflict. Often, a goal conflict implies the unavailability of any 
specific alternative to achieve both goals. In this case, the ranking of goals 
may be useful for deciding a potential dropping of a goal. However, some 
goal conflicts may be overcome by: redefining the goals, specifying the 
context in which each goal is achieved or finding alternative goal refinements 
that have fewer conflicts. 

The two key issues in managing conflicts are: tracking known conflicts and 
recording information about these conflicts, such as the circumstances that led to 
these conflicts. 

Very often, the high-level goals, problems, business rules, etc., acquired at the 
elicitation contain a number of informal and imprecise requirements. Initial ver- 
sions of a model might also contain certain redundancy, which is allowed in order to 
support the discussion and to accommodate stakeholder wishes. It is recommended 
that the output of the initial Goals Model be structured at an early stage. This task 
involves: 

• Goal classification: To improve comprehension and understanding of a multi- 
tude of goals, it maybe advisable to classify them in a matrix table, where they 
may be categorized according to origin, stakeholder, function, domain, etc. This 
will allow for comparison and analysis and will potentially uncover the need for 
further discussion based on the analysis of the patterns of the goals. 

• Goal prioritization: A prioritization of goals allows for conflict resolution 
between goals. A higher level goal acts as a constraint on a lower level goal. 

• Goal correlation: Goal correlation is perceived as the positive or negative 
interaction between goals. In general, positive correlation among goals by 
supports relationships is desirable, which implies that satisfaction of one goal 
will support the satisfaction of the other goal. On the contrary, the existence of 
antagonistic goals could prevent the satisfaction of goals. Furthermore, failure to 
recognize antagonistic goals could cause confusion throughout the modeling 
process. In addition to analyzing the goals model, goal correlations can also be 
analyzed by creating a connectivity matrix — where all goals are listed as rows 
and columns and each cell represents a relationship. In larger models this 
sometimes allows discovering new relationships. 



8.2 Business Rules Model 



The Business Rules Model is used to define and maintain explicitly formulated 
business rules, consistent with the Goals Model. Business rules may be seen as 
operationalizations or limitations of goals. Business rules are the rules that control 
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the enterprise in such a way that they define and constrain which actions may be 
taken in the various situations that may arise. These may be in the form of: 

• Precise statements that describe the way that the business has chosen to achieve 
its goals and to implement its policies or 

• The various externally imposed rules on the business, such as regulations 
and laws. 

Business Rules often form a hierarchy where lower level rules define the way the 
higher level rules or goals are implemented. Business Rule modeling is closely 
related to Goals modeling. Rules are defined by goals while also affecting the 
fulfillment of other goals. They trigger business processes and refer to concepts 
defined in the Concepts Model. Actors in the Actors and Resources Model are 
responsible for achieving and defining business rules. Business rules may also 
require certain functionality from information systems. Components of the Tech- 
nical Components and Requirements Model may, therefore, be motivated by 
business rules. 



8.2.1 Components of the Business Rules Model 

Business rules may be categorized into Derivation Rules, Event-action Rules, and 
Constraint Rules that are further classified into Static and Transition Constraints. 

Derivation rules are expressions that define the derived components of the 
information structure in terms of entities that are already present in the information 
base of the modeled enterprise. Derivation rules are introduced as a means of 
capturing structural domain knowledge that needs not to be stored. Its value can 
be derived dynamically using existing or other derived information. A derivation 
rule is, for instance, “A bad library client is a client that does not return a loan on 
time for two consecutive times.” 

Event-action rules are concerned with the invocation of activities. In particular, 
action rules express the conditions under which the activities must be taken, i.e., a 
set of triggering conditions and/or a set of preconditions that must be satisfied 
before their execution. For instance, “If the return of a loan is more than 4 days 
overdue, send a reminder.” 

Constraint rules are concerned with the integrity of the enterprise information , 
or with the enterprise activities and their permitted behavior. A constraint is, for 
instance, “the salary of an employee must not decrease.” Constraints can be further 
specialized into: 

• Static constraints apply to every state of the information base and are time- 
independent. They represent conditions that must hold at every state. A static 
constraint is, for example, “location of each copy of book is unique and only 
one.” 




8.2 Business Rules Model 



103 




Fig. 8.18 Example of rule decomposition using AND relationship 




Fig. 8.19 Example of rule decomposition using OR relationship 



• Transition constraints define valid state transitions in the information base, thus 
specifying restrictions on the behavior of the system. A transition constraint is, 
for instance, “A copy of book is missing, if the loan that includes it is overdue for 
more than 4 weeks.” 

The relationship types between rules in the Business Rules Model are: 

• Supports relationship is essentially seen as vertical, i.e., it is used to refine or 
decompose rules. 

• Hinders relationship is used to show negative influences between components of 
the Business Rules Model, and can be considered as opposite to supports. 

As in the Goals Model, there are also possible AND/OR decomposition struc- 
tures in Business Rules Model (Figs. 8.18 and 8.19). 
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• AND refinement relationships represent a set of unique sub-rules that are neces- 
sary to satisfy to support the original refined rule. 

• OR refinement relationships represent a set of alternative sub-rules. To support 
the original rule it is necessary to satisfy only one rule from the set. 



8.2.2 Notation 

The notation of the Business Rules Model is depicted in Fig. 8.20. 




Fig. 8.20 The notation used in the Business Rules Model is similar to that for the Goals Model 



8.2.3 Example Business Rules Model 

8.2.3.1 Modeling the Current Situation (AS-IS Model) 

As shown in the Goals Model, the primary goal defined by the company is the profit 
increase by 15 %. Other goals were defined to support Goal 1 . Many of the goals are 
connected to business rules, which further specify conditions for achieving the 
goals and create possibilities for the company to monitor goal achievement. In this 
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context, A4Y developed several rules to be followed by the staff in the different 
business processes. For example, the two Rules 9 and 5 are intended to support the 
objective “Reduce time to market” (Goal 2.2); see Fig. 8.21. Rule 9 supports Goal 
2.2 with the directive that the manufactured products have to be shipped daily. The 
second important rule (Rule 5) states that the manufacturing process must not take 
longer than 2 weeks. Thus, both rules support the objective of selling the products 
as soon as possible. 

A4Y has identified a number of rules that are derived from other rules, i.e., they 
are rules that build on each other. First, the rules on the refinement level must be 
met before the “higher level” rule can be applied. For example, Rule 27 aims at 
selecting the logistics service provider according to the packet size and the recipient 
country. In order to follow this rule, Rule 7 must be considered which requires that 
the shipping guidelines should be observed at all times. 




Fig. 8.21 Example of a goal and rule connections in the Business Rule Model 
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Fig. 8.22 Example of a rule contributing to several business goals 



For the manufacturing part of the business, the company has a rule (Rule 
16, Fig. 8.21) that states that an order should be triggered when the number of 
items in stock falls below a minimum inventory of 500 items. In this context, also 
Rule 5 is affected, as an empty warehouse can significantly prolong the production 
process or even halt it. By formalizing this relationship, dependencies can be 
detected quickly and support is given, regarding how this rule has to be applied 
in order to guarantee an appropriate amount of parts in stock. The rules are 
illustrated in Fig. 8.21. 

Furthermore, it may happen that the same rule can apply to multiple objectives. 
For example, the Goals 4.1 and 4.2 both are supported by Rule 6, since that 
directive specifies the maximum number of characters in the engraving and helps 
to avoid unnecessary costs and delays in production (see Fig. 8.22). 

To comply with the shipping policies and avoid legal consequences for the 
company, two additional rules are defined by management — Rule 7 is refined by 
defining Rule 8 and 10. Firstly, the product must be packed in accordance with 
international standards and, secondly, other guidelines were created to ensure 
proper billing. These two rules are visualized in Fig. 8.23 and define preconditions 
for a smooth and accurate shipping process. 

Furthermore, the management defined rules to be applied in the business pro- 
cesses as complement to the goal-related rules. Rule 26 “Report poor quality to the 
CEO” at the same time supports Rule 1 1 in control of the delivered goods and is part 
of Process 12.5. In this process, the quality control for incoming goods is carried 
out. If any defect should occur, this must be reported to the CEO (see Fig. 8.24). 

When examining dependencies between all rules defined for AA4Y, one rule is 
discovered which prevents reaching certain goals: Rule 3 defines that the CEO and 
all involved parties have to explicitly agree, if a manufacturing order or procure- 
ment order has to be changed. This means for Goal 4.1 — to just mention one 
example — that any customer order requires the explicit agreement of the CEO. If 
the CEO is not available, the production process for this order cannot be started. 
This in turn contradicts Goal 4.1 that aims to reduce the production time, since the 
required flow of information and tasks resulting from Rule 3 rather extend the 
production time than shorten it (see Fig. 8.25). 
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Fig. 8.23 Example of AND decomposition in the business rule model 




triggers 



Rule 11 

Supplier must accomplish those defined 
qualities which are regularly controlled by 
the goods inward inspection 




Fig. 8.24 Example of a rule related to both a process and another rule in the business rule model 




Fig. 8.25 Example of a rule that hinders a goal in the business rule model 

8.2.3.2 Modeling the Future State (TO-BE Model) 

A4Y decided not to invest in new machines for developing new products and 
product variants in the near future. The reason for this is the intention to increase 
sales by promotional activities, and to focus on the reduction of operational costs. 
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Fig. 8.26 Example of an updated rule model in the target model 

Accordingly, Goal 2.1 was removed in order to avoid an increase in operational 
costs. When removing Goal 2.1, the corresponding rules also had to be eliminated, 
as they have no further use (see Fig. 8.26). 

A4Y also decides to establish contracts with shipping service providers, which 
include pickup service for the goods to be shipped. Due to this proposed measure, 
Rule 9 has to be removed and replaced by Rule 28 (see Fig. 8.27). Rule 9 defines 
that products should be shipped on the day of their completion, i.e., the foreman has 
to deliver the products to the shipping service providers as soon as they are 
completed. This is considered inefficient and shall now be replaced by Rule 
28 “Products should be ready for shipping.” According to the new rule, the foreman 
has to prepare the products for shipping, but no longer has to deliver them to the 
shipping service provider. All products ready for shipping are picked up by the 
shipping service two to three times a week. 
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Fig. 8.27 Example of replacing a rule in the business rule model 




Fig. 8.28 Example of adding a rule in the business rule model 

As the company also decides to outsource part of the IT system, a new rule needs 
to be added to Goal 3.4 (see Fig. 8.28), defining that privacy has to be observed at 
all times (Rule 18). It should be noted that not every goal requires a rule. 

As a result of a thorough analysis of the rules defined in the AS -IS model, the 
management of A4Y decides to remove or replace certain rules. As already 
discussed when describing the AS -IS model, Rule 3 stating that any changes require 
the consent of each stakeholder involved and the manager him/herself hinders Goal 
4.1, reduction of production time. As a consequence, it is decided to remove this 
rule, i.e., Goal 4.1 “Reduce production time” can be performed more efficiently. 



8.2.4 Introducing More Formality in the Business Rules 

Model 

Business rules are seen as a formal part of organizational design. In many cases they 
are expressed in natural language. But in view of the inherent informality of natural 
language, formal expression of rules is needed in some cases. In 4EM this can be 
achieved by expressing business rules in the following way: 
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When {event} 

If {preconditions on entities} 
then {processes} 

It may, however, not always be possible to formulate a business rule using this 
proposed pattern. Generally, there are several ways by which business rules can be 
stated: 

• Informally such as in normal language, 

• Formally such as structured English, or 

• Formally by using specially developed rule languages, e.g., Object Constraint 
Language (OMG 2000), SBVR (OMG 2008) 

The latter two express rules in an unambiguous way that contributes to easier 
implementation of them in an information system design. Such mles should contain 
only one atomic rule, that is, a specific formal statement of a single constraint, fact, 
derivation, or term and cannot be decomposed further. For example, we can rewrite 
Rule 16: “When the stock below 500 order new” as shown in Fig. 8.29. 

From a rule written in this way, modeling participants and designers are able to 
get more precise information about the event, condition, and the process to be 
triggered; see Fig. 8.30. 

However, in a formal way it is possible to express only atomic rules. Rules that 
are more complex need to be expressed in natural or seminatural language and then 
decomposed or refined by using AND/OR relationships. Also, there may be also 
atomic rules that are almost impossible to define in a formal way, e.g., rules that are 
related to nonfunctional requirements. 



Fig. 8.29 Example of a 
single constraint 



Rule 16 

When Audit_Minimum_Stock_ET 
IF old.Stock- new.Stock > 500 
THEN OrderET.trigger 



Fig. 8.30 Example of a 
rule triggering a process in 
Business Processes Model 



Process 12.4 
Order new components 

X 

triggers 

i 

Rule 16 

When Audit_Minimum_Stock_ET 
IF old.Stock - new.Stock > 500 
THEN OrderET.trigger 
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Table 8.2 Driving questions for business rule modeling 



Question 


Motivation 


Are there stated rules and policies within the 
company that may influence this model? 


Every company has stated internal rules that 
need to be included in the model if they 
influence the problem at hand or the 
envisioned solution 


By which rules can the goals of enterprise can 
be achieved? 


This question aims to further operationalize a 
specific goal by defining rules that help its 
fulfillment 


Does a rule relate to a particular goal? 


Rules can relate to goals by supports, hinders, 
or conflicts relationships. In the case of the 
latter two relationships the conflict needs to be 
resolved by either reformulating the goals or 
reconsidering the rules 


How can this rule be decomposed into simpler 
rules? 

How can this rule be defined in an operational 
way? 


These questions aim at deeper rule 
operationalization 


How can the enterprise conform to the specifi- 
cation of the rule? How do you validate that a 
rule is enforced? 


These questions aim to establish if certain 
business processes or concepts need to be 
established in order to comply with the rule 


Which process triggers this rule? 


In the case of event-action rules there is a need 
to consider which business processes are trig- 
gered by the rule and if the process has the 
appropriate inputs and outputs in terms of 
information and/or material 


Who is responsible for this rule? 


This question aims to establish a responsibility 
for the rules in terms of Actors and Resources 
Model components (e.g., role or organiza- 
tional unit) 



8.2.5 Developing and Refining the Business Rules Model 

Business rule modeling is often linked together with modeling other types of 
sub-models. For example when developing goals there may be a need to define 
certain rules, when modeling business processes specifying exceptions may be 
needed, and when modeling concepts a need to define integrity constraints may 
arise. There are several kinds of driving questions that could be useful when 
eliciting and analyzing business rules; see Table 8.2. 

8.3 Concepts Model 



The Concepts Model is used to define the “things” and “phenomena” which are 
used in the other models. Concepts may be tangible, such as e.g. “car,” or intangi- 
ble, such as e.g. “quality.” The Concepts Model must, at least, include components 
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by which we can describe the contents of the different information sets and flows of 
the Business Processes Model. For example, the goal expression “To maintain and 
improve the library’s services” requires a definition in the Concepts Model of the 
concept “library service.” It is vital that important concepts used in other models are 
defined here to avoid the possibility of misunderstandings amongst participants and 
stakeholders. Inconsistencies are hence avoided. 

A Concepts Model includes components such as concepts , binary relationships , 
and information attributes. Also, the ISA and PartOF relationships are included in 
the Concepts Model to permit generalization as well as complex component 
modeling. The Concepts Model also allows the possibility of defining different 
“Concepts Model Component Groups.” A group of this type is simply a view of a 
part of a Concepts Model, and includes a subset of the Concepts Model’s concepts, 
relationships, and attributes. A group can be a member of another group, etc. 
Groups may overlap each other in terms of their components. 

The main purpose of the Concepts Model is to serve as a dictionary for reasoning 
about “things” and “phenomena” included in the other models. Hence the 4EM 
language for Concepts Modeling is relatively simple. A Concepts Model, or most 
often parts of it, can also be used for database design. In this case, the notation for the 
Concepts Model proposed here would most likely have to be replaced with a more 
formal data modeling notation e.g., Object-Role Modeling (ORM) (Halpin and 
Morgan 2008). The choice of modeling language does not affect the modeling 
process itself. It is generally possible to begin with the notation we describe in this 
book and then, later on, switch to more advanced concepts modeling language, e.g., 
ORM or UML Class Diagrams (OMG 2005). This may be particularly important 
when the Concepts Model is used as a requirements source for a database design. 



8.3.1 Components of Concepts Model 



The Concepts Model follows the same principles as most other modeling languages 
for data models — it consists of concepts, attributes, and a set of associations. 

Concept is something in the domain of interest and application that we want to 
reason about and to characterize and define using relationships to other concepts. 

Attribute is a component type that is only used to characterize concepts, i.e., it is 
a property of the concept (see Fig. 8.31). 

Concepts can be related to each other by means of semantic relationships, such 
as binary relationships, generalization/specialization (ISA) relationships, and 
aggregation (PartOF) relationships. 

A Binary relationship is a semantic relationship between two concepts or within 
a concept. The semantics of the relationship is defined by the modeler by naming 
it. Binary relationships are inherently bi-directional. Each direction can be given a 
name, preferably in the form of a verb phrase. The direction indicated by the arrow 
may be called the forward, or primary, direction and the opposite direction the 
inverse direction. An example of permitted multiplicities for binary relationships is 
given in Fig. 8.32. The concepts participating in a relationship can be said to play 
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Fig. 8.31 Example of a Concept and its attributes 



[ Concept 58 
l E-Shop customer] 
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places 




Concept 59 
Customer order , 



Fig. 8.32 Example of a binary relationship 



certain roles in the relationship. In the relationship “An E-shop customer places 
several Customer Orders; Each Customer Order is placed by exactly one E-Shop 
customer” (see Fig. 8.32), the customer is the one who places the order, while the 
order is what “is placed” by the Customer. 



8.3.1.1 ISA Relationships 

An ISA relationship is a specific kind of semantic relationship between concepts. If 
“A” ISA “B,” then “B” is the more generic concept and A is the specific concept. 
Establishing this kind of relationships is also referred to as generalization. The 
opposite or inverse of generalization is called specialization. 

The most significant property of an ISA relationship is that of inheritance. All 
that is specified to be true about the generic concept is also true for the specific 
concept. That means that all attributes, their values, and constraint (rules) are 
inherited from the more generic level concept down to the more specific level 
concept as are all relationships in which the more generic level concept participates. 

The subtypes that result from a particular specialization of a concept can be 
non-overlapping. Consider, for instance, the specialization of Product into 
Engraved Product and Standard Product (see Fig. 8.33). This states that no single 
product can be both engraved product and standard product, at least not at the same 
time. Such a specification is called total. 

A specialization is total when all the instances of the generic type are members 
of one specific type, i.e., when the specialization is a partition of the generic type. 
When the specialization is partial there are instances of the generic concept (type) 
that is not a member of any of the subtypes. For example customer has two subtypes 
e-shop customer and anonymous customer, but more subtypes are possible as well. 
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Fig. 8.33 Example of total and partial generalization 




Fig. 8.34 An example of a PartOF relationship structure 



8.3.1.2 PartOF Relationship 

A PartOF relationship or an aggregation is a special form of semantic relationship, 
where the interrelated concepts are “strongly and tightly coupled” to each other. 
The aggregate concept is an assembly of parts, and the parts are components of the 
aggregate. The component concepts are often subordinate to the aggregate concept. 

The most typical example of an aggregation is a part dependency, where the part 
at the top level consists of a number of components, and where each or some of 
these components at the next level are seen as aggregates, which in turn have parts. 

The PartOF relationship constmct is included in the Concepts Model for reasons of 
convenience, making it possible to use it whenever it is considered natural and rewarding 
to see and operate on something as part of a hierarchy or a structure of components. 

The example in Fig. 8.34 shows that an off-line marketing campaign consists of a 
component stmcture. It is defined to have three components: a printed advert, a brochure, 
and a poster. A brochure in turn consists of own content and third-party content. 
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8.3.2 Notation 



Notation of the Concepts Model is shown in Fig. 8.35. 




Fig. 8.35 Notation used for Concepts Modeling 

8.3.3 Example of a Concepts Model 

8.3.3.1 Modeling the Current Situation (AS-IS Model) 

A4Y sells accessories in the form of physical products. A product (Concept 6) is 
based on sample blanks (Concept 14) and can be engraved (Concept 8) or be resold 
as a standard product (Concept 7). Sample blank, also called pattern blank, is a 
basic component that can be manufactured into a product if it is faultless. If a 
production order for the production of standard products exists, in the first step a 
sample is minted or produced using a laser. Subsequently, the sample is passed on 
to production, if it shows no flaws (Concept 15). The example is shown in Fig. 8.36. 
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Fig. 8.36 Example of modeling the concept “product” in the Concepts Model 
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Rule 16 

When Audit_Minimum_Stock_ET 
IF old. Stock - new. Stock > 500 
THEN OrderET.Trigger 



Fig. 8.37 Example of modeling the concept “supplier” in the Concepts Model 



All information and properties that have been defined for the concept “Product” 
also apply to the refinement of this concept, i.e., “Product with engraving” and 
“Standard product.” Since there are no further refinements, a total ISA relation has 
to be used here. Once the requested product is produced, it can be sold. 

A pattern blank consists of different components (Concept 11), which are 
delivered by suppliers (Concept 50). The selection of suppliers is conducted by 
an Internet search (Concept 51). Among other reasons, this search will be initiated 
if the number of parts in stock (Concept 49) drops below the threshold of 
500 items — this is expressed with Rule 16 (see Fig. 8.37). In the future, the 
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Fig. 8.38 Example of the division of marketing activities in the Concepts Model 



company wants to introduce a supplier relationship management (SRM) in order to 
establish long-term relationships to suppliers and ease the task of supplier selection. 
For assessing and selecting suppliers a number of criteria were defined; see Concept 
52 and its specializations. 

The company has a certain budget available to conduct marketing measures. 
These measures are divided into online (Concept 26) and off-line marketing 
(Concept 27). In connection with both concepts, a number of measures are carried 
out, which are linked using partial PART_OF relations to the concepts. For exam- 
ple, the off-line marketing consists of sales pitches (Concept 28), the creation and 
distribution of brochures (Concept 29), and posters (Concept 30). The online 
marketing is divided in a similar manner into the concepts search engine optimi- 
zation (SEO) (Concept 31), search engine marketing (SEM) (Concept 32), and 
newsletter (Concept 33). The division of marketing activities in the concept model 
is shown in Fig. 8.38. 



8.3.3.2 Modeling the Future State (the TO-BE Model) 

With respect to the future development of A4Y it showed that the concept model 
does not require substantial modification, as the planned changes in processes and 
objectives do not have serious impact on the concepts. 

However, the company wants to establish a defined number of regular suppliers 
when introducing a supplier relationship management system (SRM). The intended 
effect is to avoid the time-consuming Internet search by establishing a network of 
regular suppliers. Due to this measure, Concept 51 is replaced by the new concept 
“Selection of regular suppliers” (Concept 67); see Fig. 8.39. 
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Rule 16 

When Audit_Minimum_Stock_ET 
IF old. Stock - new.Stock > 500 
THEN OrderET. trigger 



Fig. 8.39 Example from the target model for the exchange of concepts in the concept model 



8.3.4 Developing and Refining the Concepts Model 



It is important to understand that in the real world there may be many more 
relationships between concepts, but not all of them are relevant and necessary to 
present in the Concepts Model. Deciding on the relevant concepts and relationships 
depends on the modeling scope. The Concepts Model includes components, among 
others, that represent information, needed by or produced by processes in the 
Business Processes Model. Therefore, if there is a need for some process of the 
Business Processes Model, for instance, “Search for availability of a book in 
Library’s Catalogue,” then the Book and its Copy must be included in the Concepts 
Model, and their relevant attributes stated. 

Note that the inclusion of the information in the Concepts Model does not imply 
realization in a computerized information system. It may be manually produced, 
disseminated, and maintained as well. 

Whether concepts such as supplier and stock should be included as a component 
of the Actors and Resources Model depends on whether the concept is involved in 
any relationship as an actor or a resource which has to be documented with respect 
to components of the Actors and Resources Model or other models and their 
components. One such relationship could be that we later wish, in the Technical 
Component and Requirements Model, to state some information system require- 
ments concerning the Actors and Resources Model resource “stock.” 

Above we have exemplified a concept that, with different interpretations and 
different uses, can appear in different sub-models. It is important to distinguish 
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sharply between these different uses and to put components in the appropriate 
models at the start, before the models grow too large and confusing. 

In the Concepts Model we may use “real entities.” Experience has shown, 
however, that when performing modeling operations, it may be very illustrative, 
and supportive for human understanding, if the Concepts Model can play the role of 
a “dictionary of concepts.” General concepts like “Profit,” “Marketing,” “Sales 
Effort,” “Customer Value,” and “Productivity” can sometimes be needed to be 
documented, and their relationships discussed. It can happen that these concepts are 
introduced in texts of goal statements in the Goals Model, and need further 
definition and discussion. 

Perhaps it is important to discuss different types of “Productivity” by using 
specialization relations, and to discuss how the components are related to “Profit” 
or some specialization of it. Note, however, that these concepts, if not further 
refined as “data,” will not appear as information consumed or supplied by processes 
in the Business Processes Model. 

While modeling concepts there several driving questions that can be used to 
facilitate the modeling process; see Table 8.3. 



Table 8.3 Driving questions for concept modeling 



Question 


Motivation 


Which are the main concepts of this 
application? 


The Concepts Model needs to define the cen- 
tral concepts of the problem being modeled 


How are these concepts related? 


Relationships among concepts represent 
important facts of the problem domain 


Why is this concept needed? 


Every concept should in some way contribute 
to the clarity and completeness of the overall 
organizational design 


What do we need to know about the concept in 
the application? When and where do we need 
this ( with ref. to the Business Processes 
Model)? 


These questions help identifying relevant 
attributes of the concept 


How many instances of this concept are there? 


This allows the modeling team to consider 
what might be needed to manage this concept 
and what information needs to be known 
about it 


How does an instance of this concept come into 
existence? 

What makes an instance of this concept come 
into existence? 

What makes an instance cease to exist? 

How does an instance cease to exist? Are the 
above situations reflected in the Business Pro- 
cesses Model? 


These questions trigger the modeling team to 
consider the business processes that need to 
be modeled to deal with the concept at hand 


Is a concept type generically related to some 
other type? 


Allows identifying more general concepts and 
relationships among them 
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8.4 Business Process Model 

The Business Process Model is designed for analyzing the processes and flows of 
information and material in the enterprise. Process can be decomposed into sub- 
processes. Components of the Business Process Model are primarily motivated by 
components of the Goals Model as well as enable goals of the Goals Model to be 
achieved. 

The Business Process Model describes the organizational activities, i.e., the 
functions and processes of the enterprise. The core of the enterprise is the set of 
processes, contributing to the value of the enterprise. For achieving a good abstrac- 
tion and overview, the Business Process Model permits full freedom of decomposing 
processes into subprocesses, etc., to any level. Depending on the purpose of the 
modeling, the processes described can be existing, or future, planned processes. 



8.4.1 Components of the Business Process Model 

The components of the Business Process Model are similar to most process 
modeling approaches. Its main components are process, external process, informa- 
tion set, and material set. 

Process is a collection of activities that: 

• Consumes input and produces output in terms of information and/or material, 

• Is controlled by a set of rules, indicating how to process the inputs and produce 
the outputs, 

• Has a relationship to the Actors and Resources Model, in terms of the performer 
of, or responsible for a process, and 

• As an instance of a Business Process Model is expected to consume, when 
initiated, a finite amount of resources and time. 

External process is a collection of activities that are: 

• Located outside the scope of the organizational activity area in focus, 

• Communicating with processes or activities of the problem domain area, and are 

• Essential to document. 

External processes sometimes can be considered as sources or terminators for 
some information or material flows. A typical example of external process may be a 
customer process that requests for certain library service or receives the service. 

Information or material set is a set of information or material sent from one 
Process or External Process to another process. 

The contents of Material and Information flows between processes are described 
by referencing them to their definitions in the Concepts Model where they can be 
decomposed if necessary. Information or material flows must have at least one 
sending Process or External Process and at least one receiving Process or External 
Process. 
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8.4.2 Notation 



The Notation of the Business Process model is depicted in Fig. 8.40. 



Components of the Business Process 
Model 



Process <Number> (+) 
<Component Text> 




Information Set <Number>(+) 
<Component Text> 



Relationship Types 



Control flow between BPM components 




>- 



-> OR 



< 



Decomposition 




Fig. 8.40 Notation for Business Process Model 



8.4.3 Process Decomposition 

The higher level processes should be separated from the lower level processes with a 
decomposition mechanism. This means that a process is broken down into several 
subprocesses, each of them performing a part of the process. Each subprocess can in 
turn be decomposed into subprocesses. In theory this can be done until a level of 
atomic actions is reached. In most cases such level of detail is impractical and even if 
there is no maximum level of decomposition depth it is suggested to avoid unneces- 
sarily complex structures. In most cases three or four levels of decomposition are 
sufficient. The basic principle of decomposition is shown in Figs. 8.41 and 8.42. 
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Fig. 8.41 The process “Maintenance of the online presence” is not decomposed 




Fig. 8.42 A process “Maintenance of the online process” decomposed 

In Fig. 8.42 Process 1 is decomposed into three subprocesses, each of them 
performing a different part of the main process. Note that the incoming and 
outgoing information sets are the same on both decomposition levels. 



8.4.4 Example of Business Process Model 

8.4.4.1 Modeling the Current Situation (AS-IS Model) 

Using off-line and online marketing (terms in the Concepts Model), the customer 
(Role 2) is made aware of the company’s products. The customer has two options to 
choose a product. The first is during a sales pitch with an employee in A4Y’s shop, 
and the other one is using the product catalogue search in the e-shop (Process 2). 
The catalogue is maintained (Process 1) by the IT staff (Role 1), which includes 
updating the information (Information Set 1). If the customer has chosen a product 
(Information Set 8) and a customer profile exists (Process 24 and Information Set 
11), the customer can place an online order (Process 3). However, if the customer 
profile is missing, it must be created before ordering (Process 23). This relationship 
is shown in Fig. 8.43. 




8.4 Business Process Model 



123 




Fig. 8.43 Example of a business process model: Process of a customer order 




/ Information Flow U / 

/ Account profile / 

!_ does exist / 

Fig. 8.44 Example of a process in the business process model that is composed of several 
subprocesses 

Process 23 consists of several subprocesses. In order to create a customer profile, 
the customer must provide certain personal information (Information Set 33), includ- 
ing the name (Information Set 33.1), the address (Information Set 33.2), and the 
desired payment methods (Information Set 33.3). This information is verified subse- 
quently (Process 23.2, 23.3, 23.4) and stored (Information Set 11) (Fig. 8.44). 

As soon as manufacturing of the product ordered by the customer is finished, a 
shipping order (Information Set 3) is commissioned. The foreman delivers the 
ordered goods to the shipping service providers. In order to make this process 
more efficient, the company plans to establish long-term contracts with shipping 
service providers, which lead to a different way of shipping the goods: instead of 
separate shipping orders for each product and varying schedules for collecting the 
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Fig. 8.45 Example of a process interaction with rules and roles 



goods, the shipping service provider will collect the goods according to a 
predefined schedule (see Fig. 8.45). 

8.4.4.2 Modeling the Changes (TO-BE Model) 

The development of the “TO-BE” business process model shows that no significant 
changes of the AS-IS situation are required for the future development of the 
company. Only two modifications of the AS-IS model have to be made: The 
management of A4Y decides to extend and elaborate its online presence with a 
particular emphasis on online marketing; hence an additional process, the social 
media marketing (Process 15.4; see Fig. 8.46), is added to the online marketing. 
This step is motivated by the intention to establish an online presence in social 
networks, as they are enjoying a growing popularity. 

The second change concerns the shipping of products. As described in the AS-IS 
model, the foreman currently has to deliver the products to the different shipping 
service providers. Instead, the management intends to establish contracts with the 
shipping service providers, which includes a pickup service of the products by the 
service providers from the branches of A4Y two to three times a week. Thus, 
Process 20 is removed from the target model and an External Process 1 “Shipping 
of products” is introduced. This external process is to be carried out by the shipping 
service providers (External Process 1 in Fig. 8.47). 



8.4.5 Developing and Refining the Business Process Model 



Components of the Business Process Model must be motivated by the enterprise 
goals defined in the Goals Model. Processes of the Business Process Model are 
performed on, or with, information described by components of the Concepts 
Model, such as concepts, attributes, and relationships, or Concepts Model compo- 
nent groups. Components of the Business Process Model also are closely related to 
all components of the Actors and Resources Model. The relationships between 
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Fig. 8.46 Example for a process change in the Business Process Model 
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Information Flow 3 
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Fig. 8.47 Example for replacing and internal process with an external process in the business 
process model 

Business Process Model and Actors and Resources Model can be of many different 
types, such as: 

• actor A performs process P, 

• actor A is_responsible_for process P, 

• actor A supports process P or 

• and actor A is_a_consultant_to process P. 

In general, each Business Process Model component must, at some decomposi- 
tion level, have a relationship defined to the Actors and Resources Model. 
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Table 8.4 Driving questions for business process modeling 



Question 


Motivation 


Which are the main processes of the 
enterprises? 


The Goals Model typically governs which the 
main processes are that need to be modeled 
with respect to the problem at hand 


How are these processes related? 


Processes are related on some decomposition 
level and by using the same information flows 


Why is this process needed? 


This allows identifying the rationale for the pro- 
cess to exist. Most often this will lead to identi- 
fying inter-model links with the Goals Model 


Which information and material flows does it 
need? From which processes do they come? 
What information and material flows does it 
produce? Which processes use them? 


Processes must have input and output in terms 
of information or material sets. Without iden- 
tifying this the process model is not useful for 
implementing in the organization 


Are the information and material sets 
represented in the Concepts Model? 


Information and material sets should be 
defined in the concepts model 


Are situations that “create” or “destroy” these 
information or material sets reflected some- 
where in the Business Processes Model? 


This question helps establishing more links 
between the Process Model and the Concepts 
Model 


Which rules trigger this process? 


Some business processes are triggered by rules 
and hence inter-model relationships need to be 
established with the Business Rules Model 


Which actors are responsible for performing 
and supporting this process? 


Responsibilities for processes need to be 
specified in order for the process design to be 
considered complete. Hence, inter-model 
relationships with the Actors and Resources 
model need to be established 



It is important that modelers observe that the Business Process Model describes 
processes of the business area, and not systems or organizational units. In order for 
a component to qualify for inclusion in the Business Process Model, it must 
describe a set of possible processes, that all can be perceived to have a start and a 
stop time. At higher abstraction levels, this set of processes can be reasonably well 
defined. The main distinctions between a process (type) and an Actors and 
Resources Model component (actor) are: 

Temporal: 

• When an Actors and Resources Model component is created, it exists until it is 
disposed of or excluded from the environment. 

• The Business Processes Model describes types of processes, for which instances 
exist for a limited time. 

Instantiation: 

• The Actors and Resources Model contains components at the instance level, e.g., 
organizational units, individual resources or human actors, and roles. 

• The Business Processes Model describes processes at the class level. 

Some driving questions in Business Process modeling are given in Table 8.4. 
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8.5 Actors and Resources Modeling 

The Actors and Resources Model defines the types of actors and resources, or 
individual actors, involved in enterprise activities. The Actors and Resources 
Model describes how different actors and resources are related to each other and 
how they are related to components of the Goals Model, e.g., goals, and to 
components of the Business Process Model, i.e., processes. It describes the existing 
or future business system in terms of human as well as nonhuman resources. It 
allows the inclusion of a description of a socio-technical system to be developed 
that cannot be depicted in the Business Processes Model and Concepts Model alone. 

By studying the Actors and Resources Model and its relationships to other 
models, we can see how different actors exhibit dependencies between themselves, 
e.g., an actor may be dependent on a number of other actors with respect to 
performing a certain task or process. 



8.5.1 Components of Actors and Resources Model 

The Actors and Resources Model defines the actors and resources involved in the 
enterprise activities, articulated in the Business Process Model, or actors related to 
other models or to the development of an information system. Actors and resources 
can be individuals, organizational units, nonhuman resources, and roles. 

Individual denotes a person in the enterprise. For example: John Smith, Anne 
Dewey, etc. Individuals are identified by their name. However as names may not be 
unique they should be used sparingly. Essential persons with specific skills or roles 
are included in the Actors and Resources Model insofar as they clarify in some way 
and add meaning to the model and its relationships. Individuals may play roles and 
belong to organizational units. Individuals can, however, be related to other indi- 
viduals, to roles, organizational units, and nonhuman resources, by binary semantic 
relationships. The ISA and PartOF relationships are not relevant for individuals. 

Organizational unit can represent every organizational structure in the enterprise 
such as group, department, division, section, project, team, subsidiary, etc. For 
example: Planning Department, Technical Team, Telecommunications Group, 
Inventory Department, Computing Subsidiary, etc. Being actors, Organizational 
units can have subunits. They may also play roles and have other actors belonging 
to them. There are no predefined inter-model relationships from or to organizational 
units to any other non-actor model component of the enterprise model. Organiza- 
tional units can, however, be related to other organizational units, to individuals, 
roles, and nonhuman resources by binary semantic relationships. 

Nonhuman resources can be types of machines, systems of different kinds, 
equipment, etc. For example, “Volvo S80,” “FAX machine,” “MS Word 2011” 
are Nonhuman resources. Being actors, Nonhuman resources may have compo- 
nents and may be generalized or specialized. Nonhuman resources may also play 
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roles, e.g., Nonhuman resource “Volvo S80” plays a Role “people carrier.” Of 
course, the same Role in a different situation may be played by the different 
Nonhuman resource “Train X2000.” Nonhuman resources may be resources for 
processes. They can also be related to other nonhuman resources, to individuals, 
organizational units, and roles by binary semantic relationships. 

Roles may be played by the Individuals and Organizational units in different 
contexts. An organizational unit may for instance play the roles of administrator 
and authorizer in the same context. It may be important to identify requirements 
depending on the role they have. For example: Author, Approver, Controller, 
Supervisor, Manager, Project Leader, Process Owner, etc., are roles played by 
individuals, organizational units, or nonhuman resources. They may belong to 
one or more organizational units, and be related to other roles, to individuals, 
organizational units, and nonhuman resources by user-named binary relationships. 
Roles can be generalized or specialized, and be component roles. Roles may 
perform processes and be responsible for performing of processes and achieving 
of goals. They may also define goals. 

Binary relationships are used for describing different kinds of relationships between 
its components. The two main purposes of binary relationships between Actors and 
Resources Model components and components of other sub-models are the definition of: 

• Responsibility : a relationship between actors, between actors and business 
processes, business rules, and goals. Responsibilities can be delegated or trans- 
ferred among actors. Responsibilities can be: 

Organizational : related to the freedom of an actor to make decisions for other 
enterprise entities, such as goals, rules, resources, business processes, and other 
actors. Responsibility here also means accountability for any malfunction, 
damage, or low performance of enterprise entities. Organizational responsibili- 
ties can be represented with the following relationships: 

- actor_defines_goal 

- actor is_responsible_for goal 

- actor defines_rule 

- actor is_responsible_for rule 

- actor is_responsible_for resource 

- actor is_responsible_for business_process 

- actor owns_resource 

- actor monitors_another actor 

Operational : are related mainly to the execution of tasks and they indicate that 
an actor is committed to perform a business process or that a business process is 
assigned to an actor. We can represent operational responsibilities with the 
relationship, “actor performs process,” that means that performer of a task has 
the responsibility of properly carrying it out. 

• Dependency : is a relation among enterprise actors. An actor depends on another 
actor for something that can be either a resource or a business process. Two types 
of dependency can be identified: 
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- Operational : concerns dependencies created by the flow of work. For exam- 
ple, actors depend on others to get and use a resource that is needed by the 
business process they perform, or an actor may wait for an output from 
another actor’s process, etc. 

- Authority : concerns dependencies created because of organizational rules, 
regulations, or relationships of authority and power. For example, a user 
needs a password to work in a computer system, a clerk needs permission 
to use international telephone lines, etc. 

Dependency can be simultaneously of the operational and authority type. 

Two specific relationships are also part of the Actors and Resources Model: 

ISA is used to describe generalization relationships between roles of the Actors and 
Resources Model. The expression “A ISA B” states that components playing the 
role B also play the role A. Properties and relationships owned by A are inherited 
by B. This means, for instance, that if A is operating process P, then B is also 
operating process P. 

PartOF , used as “B PartOF A,” states that B is a component of A. We can imagine 
that these types of relationships can be useful in modeling organizational 
hierarchies, for instance that OrgUnit X PartOF OrgUnit Y, or expressing 
component relationships of technical systems. 



8.5.2 Notation 

The notation of the Actors and Resources Model is depicted in Fig. 8.48. 



8.5.3 Example of the Actors and Resources Model 

8.5.3.1 Modeling the Current Situation (AS-IS Model) 

In the actors and resource model, the case company A4Y is represented as the top 
organizational unit (OU 1), which is headed by a CEO (Role 4). All other organi- 
zational units (OU 2, OU 3, OU 4, OU 5) are part of OU 1. The role of the CEO in 
the company is taken by the individual “Alexander Mueller” (Individual 1). Fur- 
thermore, the role of the CEO may also act as sales agent in relation to customers 
(Role 2) or communicate with external suppliers (Role 8) regarding orders for his 
company. Figure 8.49 shows an example of the actors and resources model. 

Dependencies between the IT department and the “e-shop” (Resource 1) interact 
with the information system (Resource 2), which is controlled by the IT department 
(OU 3). The IT staff (Role 1) in the IT department maintains the e-shop, i.e., the 
provided information is always kept up to date and potential problems are promptly 
solved (see Fig. 8.50). 
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Components of the Actors and Resource 
Model 




Resource <Number> 
<Component Text> 



Relationship Types 



delation Name> Responsible or Dependency 



Decomposition Types 



Partial - ISA 




Total - ISA 



Organizational Unit 
<Number>(+) 
<Component Text> 



Partial - PartOf 



Total - PartOf 



> 





Fig. 8.48 The notation for the Actors and Resources Model components 



If the customer orders a product with an engraving, this order is sent to the 
production organization (OU 5) and received by the employees of the production 
organization. Subsequently, the blacksmith (Role 5) is involved in the production 
process. If goods ordered from an external supplier (Role 8) arrive, the delivery is 
received and checked by the foreman (Role 7). Both roles, the foreman and the 
blacksmith, belong to the production organization (OU 5). Once the production 
process is finished by the blacksmith, the foreman can handle the shipping. He 
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Organizational Unit 1 
A4Y 




conducts a sales conversation 




Fig. 8.49 Example of the actors and resources model 




Fig. 8.50 Example of the interaction of roles, organizational units and resources in the actors and 
resources model 

delivers the goods to selected shipping service providers (Role 9). These depen- 
dencies are illustrated in Fig. 8.51. 



8.5.3.2 Modeling the Changes (TO-BE Model) 

Based on the model of the current situation it is decided that no major change is 
needed for the future development of A4Y. The management, however, opts for two 
minor changes. The delivery of products to the shipping service providers shall no 
longer be performed by the foreman. Instead, a contract with the shipping service 
providers (Role 9) shall be established including a pickup service two to three times 
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Fig. 8.51 Example of the interaction of roles with organizational units in the actors and resources 
model 




Fig. 8.52 Example of the target model: transformation of the interaction of roles. 

each week, i.e., the foreman is contact point for the pickup of the products to be 
delivered (role 7) (see Fig. 8.52). 

Furthermore, it is decided by the management to outsource the e-shop and other 
information systems of the company to cloud providers (OU 6). Consequently, an 
external information system (Resource 3) has to be established in the future, located 
at the cloud provider. This information system includes the aforementioned e-shop 
as well as other systems to be used in the company, such as a logistics system, SRM 
or CRM. These systems are intended to interact with the company’s internal 
information system (Resource 2), which is controlled by the IT department 
(OU 3) (see Fig. 8.53). However, critical IT systems, such as the cash register 
and inventory system, remain included in the company’s internal information 
system (Resource 2). 

Although the e-shop will be outsourced, the maintenance of the shop informa- 
tion will still be performed by the company’s internal IT staff (Role 1). This also 
includes the possibility to perform extensions and further development of e-shop 
functionality. 
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Fig. 8.53 Example of the transformation of resources in the actors and resources model 



8.5.4 Developing and Refining the Actors and Resources Model 



Roles played by units or individuals can also be actors as can nonhuman resources 
of different kinds, for instance, hardware or software systems or components. Links 
between the Business Process Model components and the Actors and Resources 
Model components describe the kind of relationship that exists between a particular 
process and an actor or a resource. 

Driving questions for facilitating the modeling process and improving the 
quality of the model are given in Table 8.5. 



8.6 Technical Components and Requirements Modeling 

What has been elaborated by the Goals Model, Business Rules Model, Concepts 
Model, Business Processes Model, and Actors and Resources Model is an initial 
description of the enterprise’s design in terms of its goals, its business rules, its 
processes, its “system of actors,” and its information entities. If we wish to develop 
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Table 8.5 Driving questions for actors and resources modeling 



Question 


Motivation 


Which are the main actors of this 
application? 


Each problem domain has a number of actors 
and their relationships among each other and to 
other components of the model need to be 
documented 


How are these actors related? 


Relationships among actors are important part of 
the organization’s structure 


Why is this actor needed? 

Which resources does this actor own and 
why? 

For which resource is this actor responsible? 


These questions aim to investigate the rationale 
behind the organizational structure by 
establishing links with the goal model 


What is its purpose? 

For which process is this actor responsible? 
Which processes does this actor perform? 
Which goals are defined by this actor? 
Which business rules are defined by this 
actor? 

For which business rules is this actor 
responsible? 


The purpose of the actor is represented by its 
relationships with other sub-models (goals, 
rules, business process) 



an information system to support the processes, then there is a need to deal with 
technical information system requirements, initially in a less formal way. 

Therefore, the 4EM approach includes a simple sub-model to describe, and to 
relate to each other, initial, unclear information system requirements. This 
sub-model resembles, in structure, the goals model, and, indirectly, information 
system models. Initially one needs to develop a set of high-level requirements or 
goals, for the information system as a whole. Based on these, the information 
system is structured in a number of subsystems, or technical components. For 
each subsystem, a set of goals is then defined that are more specific as well as 
requirements. These goals and requirements have to be derived from, and be 
consistent with, the earlier sub-models discussed above. The Technical Compo- 
nents and Requirements Model can also be used to capture the existing information 
systems and IT-components in an enterprise. To capture the as_is situation is of 
particular importance, if future developments of the IT-landscape in an organiza- 
tion will be based on the existing components. The Technical Components and 
Requirements Model is an initial attempt to define the overall structure and prop- 
erties of the information system to support the business activities, as defined in the 
Business Process Model. In Fig. 8.60 the relationships between the Technical 
Components and Requirements Model and other sub-models of the enterprise 
model are shown. 
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8.6.1 Component of the Technical Components 
and Requirements Model 



The Technical Components and Requirements Model includes the following types of 
components — IS goal, IS problem, IS Requirement (that is further specialized into IS 
Functional and IS Nonfunctional Requirement) and IS Technical Components. 

Information System Goal is used for expressing high-level goals regarding the 
information system and/or subsystems or components. They may be expressed with 
measurable or nonmeasurable properties, aims, visions, or directions. Information 
system goals are typically motivated by activities of the Business Processes Model, 
and may be motivated by goals in the Goals Model. 

Information System Problem is used for expressing undesirable states of the 
business or of the environment, or problematic facts about current situation with 
respect to the information system to be developed. Information system problems 
typically hinder information system goals. 

Information System Requirement expresses a requirement for a particular prop- 
erty of the information system to be designed. The property can be functional or 
nonfunctional. A requirement expression always refers to components of the 
Business Processes Model and may refer to components of the Actors and 
Resources Model and the Concepts Model. Information system requirements may 
support or hinder information system functional or nonfunctional requirements. 

Information System Functional Requirements are used to express definite 
requirements regarding a functional property of the information system or some 
of its subsystems. Functional requirements must be clearly defined with reference to 
the Concepts Model. Preferably, a formal or at least a semiformal way of expressing 
a requirement may be needed. Every data concept, referred to in the functional 
requirement, must be defined as a component of the Concepts Model. Functional 
requirements can be directly supported by information system goals, but they are 
more often seen as refinements of the stated information system requirements. 
Functional requirements are supported by components of the other sub-models, in 
particular the Business Processes Model, but also the Goals Model. A functional 
requirement must be related to a process or a subprocess, defined in the Business 
Processes Model. 

Information System Nonfunctional Requirements are used for expressing any 
kind of requirements, constraints, or restrictions, other than functional, regarding 
the information system to be built or the process of building it. Nonfunctional 
requirements are not always definite and can sometimes be negotiated and relaxed. 
It may, for instance, happen that two nonfunctional requirements cannot both be 
satisfied in the same full degree, due to some financial restrictions. In this case, the 
level of achievement of these requirements must be negotiated. Some nonfunctional 
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requirements may hinder other nonfunctional requirements, goals, and information 
system problems. They may support, or be supported by, information system goals 
and information system requirements. They can be related to, and be supported by, 
components of the Goals Model, and processes in the Business Processes Model. A 
Nonfunctional requirement can be related to a component on the Actors and 
Resources Model with relationships “involved_actor.” 

Information System Technical Components are used for expressing any kind of 
part of the existing or envisioned architecture of the information system needed for 
supporting the enterprise design specified in other sub-models. There can be 
components, packages, services, or even entire systems. The purpose of this 
component is to specify the required IS components on a crude level from a point 
of view of a business actor. 

Relationships between these types of components of the types are supports , 
hinders , and operationalization relationships AND, OR, AND/OR. They are defined 
and permitted in the same way as for the Goals Model. Between IS technical 
components a PART_OF aggregation relationship similar to the one in Concepts 
Model is also permitted. Between IS technical components and IS goals binary 
relationships of type has_goal and has Requirement are also possible. 



8.6.2 Notation 

The notation of the Technical Components and Requirements Model is depicted in 
Fig. 8.54. 



8.6.3 Example of Technical Components and Requirements 
Model 

8.6.3.1 Modeling the Current Situation (AS-IS Model) 

In order to guarantee a smooth manufacturing process of the products, certain 
technical components (TC) are required. The main component is an information 
system (TC 1), which consists of the components “Database system” (TC 2), “e-shop 
system” (TC 3), “Cash system” (TC 4), “Ordering system” (TC 5), and the “Inventory 
system” (TC 6). There is also the requirement of the company that the “Production 
system” (TC 5) and the “Cash system” (TC 4) must support the “Inventory system” 
(TC 6). This is to ensure that the inventory information always is up to date, 
i.e., whenever the production process is completed or sales of products are registered 
the inventory information has to be updated in order to avoid availability problems 
of goods. The overall structure of the information system is illustrated in Fig. 8.55. 
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Fig. 8.54 The notation for the Technical Components and Requirements Model components 



Management also defined functionality of the “e-shop system” (TC 3) as required 
for the future. It is expected that this functionality will be provided by separate 
components, which can be used by the customers (see Fig. 8.56). A “Product 
catalogue search system” (TC 3.1) shall enable the customer to find the desired 
products faster in the variety of offered products. In addition, the “Ordering system” 
(TC 3.2) has the task to provide the customer the opportunity of online ordering. The 
third functionality shall offer supportive services (TC 3.3) to customers, which 
e.g. include supplementary product information or maintenance recommendations. 
Thus, these three components are a necessary support for the e-shop system (TC 3). 
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Fig. 8.56 Supporting technical components of the e-shop system 

Furthermore, the analysis of the current situation reveals that one of the existing 
technical components has shortcomings and causes delays in the business processes. 
The mobile data collection (MDE) device (TC 7), which the employees have to use to 
capture register changes in the inventory, is outdated and no longer supports the daily 
work in a satisfactory manner. This technical component (TC 7) has a negative impact 
on the inventory system (TC 6), which is captured by using a “hinders” relationship. In 
addition to requirements regarding the technical components, management also 
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Fig. 8.57 Example of functional and nonfunctional requirements in the technical components and 
requirements model 

defined functional requirements for future IT support. For example, the cash system 
(TC 4) should be able to create a customer profile (Functional Requirement 3), if a 
customer wants to place an order online. One of the nonfunctional requirements 
(Nonfunctional Requirement 1) specifies that authentication of a client must have 
been performed before this client can buy something online. These requirements and 
the technical components are illustrated in Fig. 8.57. 



8.6.3.2 Modeling the Future State (TO-BE Model) 

For the future, management decided to outsource the e-shop (TC 3) in order to save 
costs. Nevertheless, the e-shop (TC 3) should still remain integrated into the 
company’s internal information system (T 1) in order to allow for the IT staff of 
A4Y to maintain the entire system. When outsourcing the e-shop, a new technical 
component “external information system” has been added (see Fig. 8.58). The 
external information system (TC 8), which includes the e-shop, also has to support 
the cash system (TC 4), for example, for processing online orders. 

Moreover, management plans the introduction of a logistics system (TC 7 in 
Fig. 8.59), such as an ERP system. This logistics system (TC 7) should capture all 
inventory changes in A4Y warehouse. If the number of items in stock drops below a 
defined minimum value, the system shall automatically send a message to the 
manager. This is also a functional requirement for the logistics system. Further- 
more, the obsolete MDE devices (TC 7) shall be removed from the company and 
replaced by new equipment (TC 9). 
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Fig. 8.58 Example from the target model: Change of a technical component and related require- 
ments in the technical components and requirements model 




Fig. 8.59 Example from the target model: new technical component and associated requirements 
in the Technical Components and Requirements Model 
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8.6.4 Developing and Refining the Technical Components 
and Requirements Model 



The Information System Goals and Problems modeling components are of the same 
type as Goals Model components. They have similar rules of naming and defining 
as Goals Model components. IS Goals, for example, should also start with “The 
goal is. . . ”. However, modeling IS requirements, one should remember that the 
focus in this sub-model must be on IS requirements and components, and not on 
general organizational or business issues. The components of this sub-model must 
also be measurable and verifiable, since they form the basis of the design of the 
Information System. Expressions like “better than,” “bigger than,” “the best,” etc., 
do not normally contribute to the understanding of a particular requirement. The 
components of this sub-model must be closely related to the components of the 
Business Process Model, Goals Model, or Business Rules Model. 

The main driving questions in Technical Components and Requirements Model 
modeling are (Table 8.6): 



Table 8.6 Driving questions for technical components and IS requirements modeling 



Question 


Motivation 


Which constraints and standards exist regard- 
ing communication with existing systems or 
existing hardware? 


This question aims to identify what other 
information systems are potentially influenc- 
ing the business design currently being 
developed 


Which are the important requirements regard- 
ing nonfunctional requirements type X where X 
can be e.g. security, or availability, or perfor- 
mance, etc.? 


This question addresses nonfunctional 
requirements for the system, which is an area 
often overshadowed by the focus on functional 
solutions 


Which constraints are there regarding existing 
software or programming systems that are to 
be used? 


The new solutions will have to fit in the 
existing IT architecture and technologies used, 
and hence it this needs to be considered 


Which economic, personnel, political, or other 
constraints are there? 

Are there legal restrictions to developing the 
system? 


These questions probe for possible constraints 
with respect to the implementation and usage 
context of the envisioned IT solution 


Can this requirement ( or information system 
Goal, or ...), be refined more clearly (perhaps 
decomposed ) and in a way that it can be mea- 
sured or verified? 

Considering this goal! process! rule, what IS 
requirements would support it? 


These questions aim at eliciting more detailed 
IS goals and requirements needed for 
supporting the overall business design 


What IS or IT-components are currently used to 
support business processes? 


This aims at capturing the current state in the 
enterprise? 

This aims at capturing the current state. 
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8.7 Relationships Between the 4EM Sub-models 

The previous sections explained the purpose of each 4EM sub-model including 
components and relationships. The references, or links, between the 4EM sub- 
models were also mentioned but will be recapitulated in this section. The essential 
links between the sub-models are shown in Fig. 8.60. 

In developing a full enterprise model, links between components of the different 
sub-models play an essential role. For instance, statements in the Goals Model 
might require that different concepts used in the statements have to be defined more 
clearly. This is done in the Concepts Model, and a link is specified between the 
corresponding Goals Model component and the concepts in the Concepts Model. In 
the same way, goals in the Goals Model motivate particular processes in the 
Business Processes Model. The processes are needed to achieve the goals stated. 
A link is therefore defined between a goal and the process to be carried out to 
achieve it. Links between models make knowledge traceable. It is, for example, 
possible to see why certain processes and information system requirements have 




Fig. 8.60 Relationships between sub-models 
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been introduced. Figure 8.60 provides an overview of links between the 
sub-models. 

Inter-model links are shown with dashed arrows. The example displayed in 
Fig. 8.61 illustrates different links between sub-models of the enterprise model. 

Links between the Goals Model and the Concepts Model are normally used to 
explain a component of the Goals Model by pointing, from a Goals Model compo- 
nent, to one or more components of the Concepts Model referred to in the descrip- 
tion of the Goals Model component. For example the Goal 2.1 “to develop both new 
products variants and versions” refers to concept 6 “Product.” In CM concept 6 is 
further explained. 

Links between the Goals Model and the Business Processes Model typically 
relate to goals of the Goals Model to processes of the Business Process Model with 
a “motivates” relationship. For example: goal 2.2 “decreasing the time to market” 
could initially motivate a particular, high-level process in the enterprise, e.g., 
process 13 “Create a standardized product.” 

Link types between the Goals Model and the Actors and Resources Model can 
mean several things: they may motivate or require the introduction of particular 
new actors, e.g., Customer Relations Agents (motivated by the goal to improve 
relationships with customers), or they may describe which Actors and Resources 
Model component are responsible to achieve a particular goal or defines it, etc. 
e.g. in Fig. 8.61 role 5 Blacksmith is responsible for Goal 2.2. 

Links between the Goals Model and the Business Rules Model typically describe 
how different components of the Goals Model are implemented in terms of business 
rules of the Business Rules Model. For example, the goal 2.2 “to decrease time to 
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market” is supported by a business rule 5 in Business Rules Model which states that 
the manufacturing process has to be completed within 2 weeks. There are more 
examples about Goals Model and Business Rules Model interconnection in 
Sect. 8.2 about business rule modeling. 

Links between the Business Rules Model and the Business Process Model 
typically describe how processes of the Business Process Model are triggered by 
business rules of Business Rules Model. Business processes can also support 
business rules. For example process 13 “Create a standardized product” supports 
Rule 5. In Fig. 8.62 Rule 1 requires that customers should be signed in to place an 
order. 

Links between the Business Processes Model and the Concepts Model are 
typically between Information Sets of the Business Process Model and components 
of the Concepts Model. See for example Fig. 8.62. 




Fig. 8.62 Links between information sets in the Business Process Model and Concepts Model 
components 
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Fig. 8.63 Fragment of an Actors Resources Model showing that some roles are responsible for 
rules 

Links between the Business Process Model and the Actors and Resources Model 
typically describe how different components of the Actors and Resources Model are 
related to or involved in processes of the Business Process Model. Examples of link 
names are performs, is_responsible_for, and supports. For example, the role IT 
employee performs the process “Maintain online presence”. 

Links between the Actors and Resources Model and the Business Rules Model 
typically describe how different components of the Actors and Resources Model are 
related to business rules in the Business Process Model. Common link names are: 
defines, is_responsible_for. For examples, see Fig. 8.63. 

Links between the Technical Components and Requirements Model components 
and the other model components show why certain components exist and how they 
contribute to the business, i.e., they help the business and IT alignment. Most 
typically, business process and goals motivate information system goals, informa- 
tion system requirements, and components; see Fig. 8.64. 

Model components may thus be linked in a number of ways. Which links should 
be established depends on the purpose of the particular 4EM project. Each produced 
Enterprise Model has a purpose and focus and the links within each Enterprise 
Model should therefore reflect these. Every link represents a statement, about the 
enterprise and possibly its information systems requirements. The semantics of 
every such link should be analyzed carefully. There is, however, a set of minimal 
links that should be defined for the representation to be considered complete. 
Figures in this section show some of the links between sub-models in the A4Y 
case. More about inter-models links from the perspective of model quality is given 
in Sect. 12.3.5. 
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Functional Requirements 
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Fig. 8.64 Inter model links related to IS technical components 



8.8 Auxiliary Modeling Components 

In previous sections we have described the 4EM sub-models and their components. 
In addition to these “ordinary” modeling components, it is sometimes useful to 
extend the enterprise model with some additional modeling components. The 
reasons for doing so may vary. One reason, for instance, is to improve the expres- 
siveness of the model, or to allow more “freedom” for the modeling team. This is 
most often the case in the first modeling sessions, where the most important task is 
to generate initial ideas and to familiarize participants with the modeling process. 

The types of modeling components one may add to any sub-model of EM are not 
strictly prescribed or defined. The only requirements are that everybody in the 
modeling group accepts and understands the meaning of these and that the model- 
ing facilitator accepts that particular extension of the method as beneficial. Some of 
the added auxiliary modeling components can later be reformulated using the 
regular component types. 
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Fig. 8.65 A fraction of a Goals Model containing several auxiliary modeling components 



The most common additional modeling components modelers use are the 
following: 

• Comments — usually clarify some of the modeling components, or the whole 
model, or they contain some information that the modeling group found important, 
though difficult to express in terms of the ordinary modeling components. Com- 
ments may also contain directions for further elaboration of the model. If comments 
address some particular modeling component these are interlinked by arrows. 

• Development actions — used to express concrete actions for development of a 
model, refinement of a particular modeling component, or a group of compo- 
nents, or an action needed in the project, for example, in order to gain more 
knowledge about a certain design alternative. 

• Assumptions — used in a similar way to the ordinary modeling components. We 
use assumptions to express hypothetical types of facts. They can be lined to any 
other modeling component by types of links such as motivates, supports, hin- 
ders, conflicts, etc. Later, during the elaboration and refinement phases of the 
model, assumptions can be transformed to opportunities, problems, weaknesses, 
threats, goals, processes, information system requirements, etc. 

Examples of some auxiliary modeling components are given in Fig. 8.65. 
However, these are not the only modeling components that may be included in 
the Enterprise Model. Sometimes it is even easier to replace a whole sub-model 
with another. For instance, if the notation of the Business Process Model is not 
suitable for a particular task, it can be replaced. However, the integrity of the inter- 
model links must remain consistent as previously described. 











Chapter 9 

Project Organization and Roles 



The ability to carry out Enterprise Modeling in practice requires not only the basic 
methodological knowledge covered in Chaps. 7 and 8, but also suitable project 
organization in the enterprise in question. This chapter describes how a 4EM 
project should be set up in practice, including both the roles involved in the project 
team and the organizational prerequisites in the enterprise in question. It also 
illustrates typical project phases and discusses options for implementing the par- 
ticipatory approach. The principles and recommendations presented here also apply 
to other EM approaches that share the same overlying philosophy of multi- 
perspective and participatory modeling. 

The chapter begins with an overview of the project phases in Sect. 9.1 and then 
deals with the most important phases in Sects. 9. 2-9. 8. Change management in EM 
projects is briefly discussed in Sect. 9.9. 



9.1 Overview of Project Phases 

The 4EM approach is not merely intended to produce an enterprise model, but to 
serve as the basis for problem solving, organizational development, and change 
decisions. The success of the method and its result also depend on how the approach 
is introduced in an enterprise and how the modeling process is carried out. This 
chapter will set out guidelines for introducing and using the approach in an 
organization. Even though this approach and its predecessors have been used and 
documented for several years, the practical implementation of a method by its users 
(e.g., work distribution, procedure, component selection, etc.) changes over time. 
These guidelines should therefore be considered as knowledge that is subject to 
constant development and expansion. 

Among those who have used the 4EM method in past projects, the method has a 
reputation for offering the following benefits: 
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• The method gives structure and comprehensibility to the modeling process 

• The method adds clarity and rigor to the model representation 

• The method supports organizational learning and helps to preserve organiza- 
tional knowledge 

• The method helps to make changes and restructuring in an organization easier to 
achieve 

In practice, it has also been observed that 4EM is difficult to explain due to its 
high level of flexibility in individual cases, because false expectations can be raised 
particularly at the start of a problem solving process. The risk of “overestimating 
and simplifying” often leads to the belief that the 4EM approach can “magically” 
solve hard problems. Despite its versatility, it is important to ensure that the various 
phases and modeling activities are consistently integrated when using 4EM. 

This chapter will primarily describe the structure and progression of an EM 
project in an organization using the 4EM method. In doing so, it will set out 
prerequisite, goal definition, and communication guidelines for conducting a 
modeling project, as well as basic principles for organizing modeling projects. 

A modeling project usually involves a number of phases. The next sections of 
this chapter explain the typical main phases of such a project as well as the issues 
and problems that arise in the process, and propose suitable solutions: 

1. Define scope and objectives of the project (Sect. 9.2) 

2. Plan for project activities and resources (Sect. 9.3) 

3. Plan for modeling session (Sect. 9.4) 

4. Prepare modeling session (Sect. 9.5) 

5. Conduct modeling session (Sect. 9.6) 

6. Analyze and refine models (Sect. 9.7) 

7. Present results to stakeholders (Sect. 9.8) 

Figure 9.1 describes the project phases in the form of a process model. It should 
be considered as a stereotype process, which needs to be adapted to fit each 
individual project because in real-life projects the actual steps and information 
sets might differ slightly. It is also possible that additional steps are needed, e.g., to 
ensure integration with other development projects or to involve a broad group of 
stakeholders. 

The EM process follows generic principles of carrying out projects for various 
purposes. This is because we strongly believe that aligning EM activities with the 
general project activities improves stakeholder acceptance of the modeling way of 
working. 

Table 9.1 shows how different actors are involved in the steps of the EM process. 
More about the actors involved can be found in Chap. 10. 

Throughout this chapter, references will be made to processes and information 
sets in this model. In the beginning of each second level section, an overview of the 
subprocess in question is provided, before it is discussed in more detail. 
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Fig. 9.1 The EM process model showing processes and information sets (Persson and Stima 
2010 ) 
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Table 9.1 Actor involvement in the EM process steps 



EM Process Step 


Problem 

owner 


Domain 

expert 


EM project 
leader 


EM 

facilitator 


Tool 

expert 


PI Define scope and objectives 
of the project 


R 




P 






P2 Plan for project activities and 
resources 


R 




P 


P 




P3 Plan for modeling session 


P 




R 


P 




P4 Gather and analyze back- 
ground information 






P 


R 




P5 Interview modeling 
participants 




P 




R 




P6 Prepare modeling session 


P 




P 


R 




P7 Conduct modeling session 




P 




R 


P 


P8 Write meeting minutes 






P 


R 


P 


P9 Analyze and refine models 


P 




P 


R 


P 


P10 Present the results to 
stakeholders 


R 


P 


P 


P 





R responsible, P participates 



9.2 Define Scope and Objectives of the EM Project 

We assume that the EM project is commissioned either as a result of selling 
consulting services or that another in-house development project has decided to 
address a specific problem area by a modeling approach. In either case, there 
usually exists an initial problem statement (information set 1 in Fig. 9.1) and an 
organizational actor that will benefit from solving the problem — the problem 
owner. 

At this stage the problem owner and the EM project leader should discuss the 
problem to find its boundaries, what the likely ways of solving it might be, and what 
the expected outcomes are. This would form a project definition (information set 
3 in Fig. 9.1). In this process model we assume that the organization has already 
assessed its suitability for using the participative approach to EM, but if it has not 
been done, or some doubts arise (e.g., a strong sense of hidden agendas) then the 
EM project leader should assess the situation in the organization. 

The problem should also be assessed for being suitable for EM. More about 
assessing the organization and the problem at hand is available in, e.g., Nilsson 
et al. (1999), Persson (2001), as well as Stima et al. (2007). If the organization or 
the problem is found to be unsuitable for EM, then the problem owner and the 
project leader should choose other ways of solving the problem, e.g., by the 
consultative approach or by brainstorming. When dealing with complex and/or 
wicked problems (Rittel and Webber 1984) it might be difficult to formulate a clear 
problem definition. In such cases the project might organize a modeling session 
with an objective to find out what the real problem is and how to tackle it. 
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9.2.1 Establishing the Project in the Enterprise 



Conducting an Enterprise Modeling project only makes sense if it meets with 
approval and support in the enterprise. This requires executives or budget managers 
and those responsible for the divisions in question to be convinced that the project is 
beneficial to their areas of responsibility as well as to the organization as whole. In 
order to justify the human and monetary resources required for a modeling project, 
it is often necessary to discuss the expected benefits during project initiation. 

The following aspects can generally be used when highlighting benefits: 

• The project creates value that contributes to the overall success of the enterprise 

• Cost savings through process efficiency and structural improvements 

• Enhanced competitive advantages 

• More efficient IT support for critical business processes 

• Improvements in the documentation and transparency of organizational 
processes 

• Expansion into new markets 

Preparation for a 4EM project should involve not only executives, but also 
employees, specialists, and user groups. When changes are initiated that affect 
our status quo, it is human nature to be rather cautious and often distrustful if we 
cannot assess the potential changes. It is therefore important to establish trust by 
briefing those concerned according to their initial situation and interests — in other 
words, motivation points should be produced for the parties involved. These 
motivation points may take very different forms depending on the individual’s 
role and position. For instance, executives are motivated more by the project’s 
value contribution to the overall success of the enterprise, but staff members may 
instead be motivated by work process improvements which they have initiated. The 
enterprise stakeholders who are relevant to the project should (be made to) feel 
confident that the modeling project is not a threat to their employment or positions, 
but in fact is intended to support and improve day-to-day work. Concrete examples 
from previous successful projects within the enterprise or elsewhere should be used 
as a rationale. 

Stakeholder analysis is intended to assist in identifying project participants, their 
interests, and potential motivation points. To this end, the following questions 
should be answered: 

• Who has an influence on the project? 

• Who is affected by it? 

• What expectations does the individual/group have of the project? 

• What is the attitude towards the project (positive, negative, or neutral)? 

• What degree of influence does the individual/group have (low, medium, high, or 
crucial)? 

• Are there are any competing projects (in terms of the results, budget, or political 
power)? 
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The potential effects on those involved should be classified according to level 
(none, low, medium, high, or very high) and type (positive, negative, or neutral). 

From the project goal, the time frame for implementing changes, and the 
stakeholder analysis, it is possible to identify the project type or the significance 
of the project for the enterprise. Firstly, enterprise policy projects and strategic 
projects can be distinguished. Both are highly interdisciplinary and 
interdepartmental, and hence offer potential for conflicts. Enterprise policy projects 
are often marked by a specific task (e.g., software rollout), while strategic projects 
may feature alternative scenarios (reorganization) and a longer duration. It is also 
possible to identify operational and innovation projects, which, as a rule, are less 
socially complex (e.g., due to being limited to certain departments or teams) and 
have shorter implementation timescales. Operational projects have a very limited 
solution scope and usually are rather short. 

At the end of the preparatory phase, the project team should be able to answer the 
following questions: 

• Who instigated the project and why? 

• Who is and who must be informed of the project goals/the problem at hand? 

• Who is needed to initiate the project and who is impacted by the effects of the 
project? 

• Have the answers to these questions been documented in a project description 
and approved in a project order by the appropriate managers? 

• Are there any aspects of the project that cannot be mentioned or documented 
openly (pointing to hidden agendas)? 



9.2.2 Project Goal 



There can be a wide variety of reasons for using an EM approach to solve a certain 
problem in the organization. Regardless of the reason for the project or its trigger, 
however, the project goal should be defined at the start of the modeling project. This 
also involves establishing the expected outcome, or what the result should be at the 
end of the modeling project — “What problem is the method intended to solve, and 
what benefit will it provide?” In the course of the modeling project, the project goal 
is generally further refined by a Goals Model and made more concrete by other 
sub-models, such as modeling goal-related business processes. 

Definition of the project goal requires some initial knowledge about the nature of 
the problem at hand. 4EM provides methodological support for this through goal/ 
problem modeling. By analyzing the problems that have been observed and iden- 
tifying subproblems and the affected or associated processes and organizational 
units, it is necessary here to determine which parts of the enterprise should be 
included in a model of the actual situation because they are affected by the 
problems or the solution, and what areas need not be investigated. Although the 
goal/problem model is the focus here, it should be supplemented by initial versions 
of the business process model or stakeholder/resource model. 
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The process of defining the project goal could take the following form: 

• Preparing for goal and problem modeling by selecting participants from the 
enterprise (enterprise employees who know both the problems that have 
emerged and the processes and organizational units affected), filling the model- 
ing team roles (particularly the role of moderator), agreeing deadlines, and 
booking rooms. At this stage, the employees selected should be the project 
commissioner or other relevant stakeholders on the management/problem 
owner level because the focus of modeling at this stage is to negotiate the project 
goal with the commissioner. 

• Conducting a modeling session to create a goal/problem model, often using 
conventional tools and plastic sheets. This stage includes identifying relevant 
business processes (without refining them) and relevant stakeholders or 
resources 

• Editing the results after the session 

• Holding a workshop with the modeling session participants to present the results 
and discuss their factual accuracy 

• Deriving and documenting the project goals together with the modeling work- 
shop participants and those responsible for the pre-project planning in the 
enterprise 

The following example is intended to illustrate how a project goal can be 

gradually edited and thus refined by using various sub-models. 



Example 9.1. Gradual Development and Refinement of a Goal Model 

The case study company A4Y wishes to develop a strategy for its long-term 
development of their human resource capital. This application will initially 
concentrate on the Goals Model. 

• What are the company’s long-term goals in general? 

• Which goals regarding human resources are recognized and how are these 
goals related to the company’s long-term goals? 

• Which problems are experienced and which external threats and con- 
straints do exist, etc.? 

This type of analysis and goal modeling may very well also introduce the 
need for improved conceptual analysis and modeling of concepts essential for 
the problem at hand, e.g., 

• What do we mean by “human resource”? 

• How can we measure the current status regarding human resources? 

• What do we mean by “competence” and how do we measure competence? 

• What kind of competencies may we need in the future regarding the stated 
goals? 



(continued) 
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Example 9.1 (continued) 

The above questions will help identifying concepts and creating a Concept 
Model. The analysis of goals and concepts may also lead to the development 
of a Business Processes Model. 

• What qualification measures will be offered to the employees, how can 
these measures be booked and how are they implemented, and what 
support for competence development is realized by these processes? 

• Which capabilities are required for implementing and performing these 
processes? 

• What kinds of future competences are required to reach the goals defined? 

• Should we be interested in developing a future “system” for developing 
and maintaining human resources in the company in the future? New types 
of positions, roles, and skills may require developing further the Actors 
and Resources Model. 

Regarding the information system support, the overall question to be 
addressed may be formulated as: “Does our current set of information sys- 
tems satisfy the need for information support for the long-term strategy of the 
company, and — if not — what has been changed to arrive at a satisfactory 
solution?”. This question involves, more or less, all the models described in 
Chap. 8. First, the goals of the future situation must be analyzed, as described 
above. Next, based on this set of goals, the set of business rules and processes 
must be examined and redesigned. A new Actors and Resources Model will 
most probably be developed. The established information systems must be 
described with their properties in a Technical Components and Requirements 
Model (TCRM version 1). Afterwards, a model of the future set of required 
technical components and their requirements (TCRM version 2) must be 
developed based on documented goals, rules, processes, concepts, and actors 
for the future business system. A comparison between the properties of the 
current technical system (TCRM version 1) and requirements of the future set 
of information systems (TCRM version 2) provides here the basis for ana- 
lyzing needs for changes and further developments. Clearly, in many cases 
different alternatives of future information systems may be analyzed. 



The above example shows that a relatively unpretentious application case, like 
the strategy for long-term development of human resource management, requires 
different perspectives of the enterprise and nearly all 4EM sub-models. A 4EM 
project has to start from clearly defined scope, task, and expectations with respect to 
the results of the project. The tasks and expected results have to be clear to the 
stakeholders involved in the project. In this context, the following questions can 
support defining a project’s targets completely and concisely: 
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• What is the goal of the modeling project, i.e., which problem has to be solved 
and which goals shall be reached? 

• What is outside the scope of the project, i.e., what is not to be considered within 
the project? 

• Which benefits have to be reached at what point in time for what stakeholder 
group? 

• Who is/are the target group/s of the project results? Who is the recipient of the 
final deliverables of the project? 

• How does the project support the enterprise strategy and which goals are 
supported? 

• Which priority does the project have for the enterprise? 

• What is the intended time frame for the project? 

• Which frame conditions, budget frames, and expectations exist with respect to 
the project? 

• Which risks exist and difficulties have to be expected? 

• Which milestones have to be reached and which deliverables have to be pro- 
duced at what point in time? 

In Chap. 8 we have formulated a set of general driving questions for each of the 
4EM sub-models. The example discussed here shows more concrete operationa- 
lization of those questions with respect to the particular modeling problem. The 
modeling facilitator prepares an initial set of such questions during process 6 in 
Fig. 9.1. 

There are two alternative views when it comes to defining the problem at hand. 
One stresses the importance of obtaining a clear problem definition, assuming that it is 
possible to acquire such a clear definition. The other assumes that clearly defined 
problems in most cases are illusions. Rather they are detected as the project pro- 
gresses. This has to do with the fact that problems are different in terms of complexity. 

Problem complexity influences the project planning in terms of necessary 
activities and resources. Three types of problems can be observed: 

- Fairly simple problems 

These problems are possible to clearly define and they often have a perceiv- 
able solution. They do not require the coordination of a large number of different 
preconditions, activities, actors, and resources. 

- Complex problems 

These problems have a fairly clear definition. They often have a perceivable 
solution, but they require the coordination of a large number of different pre- 
conditions, activities, actors, and resources. 

- Wicked problems 

These problems are ill- structured. They have no clear problem definition and 
there is no way of measuring that the problem has been solved. 

In case of simple and complex problems, planning of the project can proceed. 
Note, however, that the complex problem will need an experienced project manager 
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and extra resources for coordination activities. If the problem is considered wicked, 
the project should be carried out in three phases: 

1. A pre-study phase where 4EM modeling, particularly goal modeling, is used to 
negotiate agreement to the main scope of the project. This is described in the 
example above. 

2. A negotiation phase, where the actual project is negotiated and planned. Since a 
wicked problem comprises many unknown factors, the customer must be made 
aware of them and related risks. 

3. A completion phase, where the defined problem is solved as best can be done. 
Preferably, the project plan should contain a number of evaluation steps, where 
the results of the project are continuously evaluated and the overall scope is 
reconsidered before continuing. 



9.3 Plan for Project Activities and Resources 

At this stage the EM project leader, problem owner, and facilitator plan specific 
activities to be carried out. This includes the overall number and schedule of 
modeling sessions, the issues addressed in them (information set 5 in Fig. 9.1), as 
well as indicating relevant domain experts to be involved in the modeling sessions 
later (information set 6 in Fig. 9.1). Additional issues to pay attention to at this stage 
are risk assessment, resource allocation, both for the modeling expert team and for 
the domain experts, and establishing project groups’ overall authority, i.e., mandate 
to solve the problem. 



9.3.1 Project Activities 



The exact activities of a modeling project should be set out in a project plan that 
identifies the modeling activities to be carried out and defines work packages from 
them. A work package groups together modeling tasks with related content and 
defines the deadline by which they should be completed, the necessary effort, and 
the result to be produced. The content relationships between work packages can be 
used to establish the order in which they should be handled, or whether certain work 
packages should be completed in parallel. This chronological order is defined in the 
project plan, which should also define the work package responsibilities. Further 
general information on project planning techniques and the definition and use of 
work packages can be found in project management literature. 

The project goal determines what modeling activities are required in a project, 
and therefore also which work packages are needed. This means that it is impossible 
to generalize for all projects. 
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9.3.2 Project Organization 



The project organization generally specifies what roles are involved in carrying out 
the project and what tasks and responsibilities these roles entail. Experience from 
previously completed 4EM projects recommends a project structure for Enterprise 
Modeling that contains both roles specific to modeling projects and roles that are 
generally found in project organization. The roles specific to modeling projects 
include the moderator and the modeling group featuring domain experts and 
method experts. General project organization roles are the project leader, the 
steering committee, the quality manager, and the reference group. 

In a large-scale modeling project, the steering committee is the project’s topmost 
decision-making body, to which the project managers report. The quality manager’s 
role supports the steering committee by reviewing the project results. The project 
team may include multiple modeling teams. Each team should be led by a moder- 
ator and is also made up of domain and modeling experts. In addition to the 
modeling teams, there usually is a method manager, who is responsible for method 
and tool selection and coordination of individual activities. Reasonably large pro- 
jects need a documentation manager who is responsible for documenting and 
versioning the modeling results. 

In smaller projects, the steering committee is usually omitted. The manager that 
commissions the project within the enterprise, and the project leader who is in 
charge of the modeling activities frequently assume these duties. The domain 
experts involved in the modeling, rather than being specifically assigned to a 
separate role for the project, perform quality assurance. Tool and documentation 
management roles are also incorporated into the modeling team. 

These project organization roles are briefly introduced below. Further informa- 
tion on general project organization roles can be found in the standard literature on 
this subject. 

• Project management in large-scale projects often consists of two project man- 
agers: the manager from the commissioning enterprise, often called the internal 

project manager or customer representative, and the manager of the modeling 

activities, often called the project manager for modeling. 

Jointly, these two project managers are responsible for: 

- Project planning 

- The day-to-day project management (incl. supervision of time plans, resource 
consumption, and costs) 

- Reporting to the steering committee 

The internal project manager is responsible for and has to coordinate 

- Provision of documents required for the modeling project 

- Selection of domain experts required for the modeling and releasing them 
from their regular duties to allow their participation in modeling activities 

- Communication of project goals, expected results, and achievements within 
the enterprise 
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- Providing facilities and technical infrastructure for the modeling activities in 
case they are performed within the enterprise 

The project manager for modeling is responsible for 

- Planning and organization of all modeling activities following the selected 
method 

- Reaching high-quality modeling results, e.g., by organizing workshops for 
presentation and validation of the models and results 

- Assigning modeling experts to roles and to modeling activities, and 

- Achieving the defined project goals and results. 

In small to medium size projects the project manager for modeling may also 
be fulfilling the role of modeling facilitator. 

• The steering committee typically includes members from different areas or 
departments of the enterprise who are involved in reaching the project’s objec- 
tives or have an interest in the value the project intends to create. This could be 
heads of departments, budget responsible managers, or employee representa- 
tives. The steering committee will typically be responsible for: 

- Supporting and “selling” the project within the organization, i.e., internal 
communication of project goals, 

- Deciding on the final project plan, 

- Obtaining official acceptance of milestones and deliverables based on the 
results of quality control measures. 

- Deciding about changes in project plans in case of new requirements and 
delays in project work, 

- Supporting the acquisition of resources and assigning them to the project, and 

- Deciding about resource allocation 

• The quality assurance is responsible for systematically ensuring the quality of 
project results. This includes: 

- Definition of quality criteria for the different kinds of project results (see 
Chap. 12 with respect to the quality of enterprise models), 

- Development of a quality plan (which quality result will be evaluated at what 
point in time according to what criteria?) 

- Documentation of the results of quality control activities, 

- Reporting to project management and steering committee. 

• The reference group typically consists of domain experts and experienced 
employees of the enterprise who are familiar with structures and processes in 
the enterprise. The reference group is responsible for: 

- Supplying domain knowledge, knowledge about organization units involved, 
expertise, and information, 

- Examining and evaluating the results, and 

- Integration of modeling results of different teams into a consistent whole. 
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• The modeling group are the persons participating in modeling activities, i.e., 
there can be different modeling groups for different modeling activities 
depending on the purpose of modeling. The tasks of the modeling group are to: 

- Actively participate in the modeling sessions, 

- Contribute with domain knowledge, 

- Ensuring that the models contain relevant and valid domain knowledge, and 

- Assist the facilitators with structuring and describing the models. 

The composition of the modeling group should meet a number of criteria: 

• There are persons from various parts of the enterprise enabling the broadest 
range of knowledge and views to be available, 

• The group has adequate domain knowledge, 

• The group has the necessary authority to suggest organizational change and 

• The group comprises enthusiastic, open-minded, and cooperative people. 

• The facilitator s task is to direct and guide workshops and modeling session, 
which includes several tasks: 

- Prepare modeling sessions 

- Manage sessions in accordance with the method used 

- Manage the modeling process 

- Make sure that all participants are included in the modeling process 

- Make sure that the goals of the modeling activities are reached 

- Support the modeling group in acquiring knowledge and ideas from each 
other 

Like other types of projects, a modeling project can also be unsuccessful without 
sufficient resources and skills. The individuals involved must be expressly allowed 
time to participate. Moreover, provisions with regard to modeling tools, e.g., 
modeling kit, rooms, IT, and (if applicable) external domain experts, must be 
organized and made available by the enterprise. 

The project managers and participants who are involved in the modeling process 
must know and understand the goals and expected results of the project. The 
purpose, goals, and scope of the project must be documented by the time that the 
project organization and project plan are set, which should also include the alloca- 
tion of resources (staff, responsibilities, time, money, IT, and other resources). The 
type of quality assurance with regard to the quality of the results, adherence to 
milestones, and the validation process must also be defined, generally in a separate 
quality assurance plan. The outcome of the quality assurance activities should also 
be documented. 

Once the project organization has been established, it should be possible to 
answer the following questions: 

• Who is directing the project, and who is part of the project team? 

• Have the initiators, commissioner, other authorizers, committees, and reference 
groups been identified, informed, and involved? 

• Have the modeling group participants been identified and involved? 
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• Are the necessary resources available? 

• Has an appropriate reporting system been defined? 

• What modeling sessions should be conducted, when, with what goals? 

• What skills and which domain knowledge are required? 

• What roles are required for which of these sessions? 

The project organization has to be established on the basis of the project goal, 
which means all of the roles required for the project are filled. The roles that are 
generally required in participatory modeling are covered in Sect. 9.5. The project 
plan for the modeling project is created, including the schedule and an estimate of 
the effort involved. Provision of the necessary resources must be agreed with the 
enterprise. Tools and other necessary aids must be made available or procured. 

A typical mistake in planning for resources in an EM project is to underestimate 
the resources needed for preparing as well as documenting and reporting on 
modeling sessions. We suggest distributing effort as follows: preparing for model- 
ing sessions ~40 %, carrying out modeling seminars ~30 %, and documenting/ 
reporting -30 % of the total effort (Persson 2001). This distribution of resources is 
only given as an indication; depending on the project’s aim and duration they may 
actually vary by up to 10 %. For example some very short projects might not require 
extensive documentation and more complex projects might require even more 
in-depth preparation. 



9.4 Plan for Modeling Session 

The first modeling session in a modeling project simply must not fail. This is the 
time to show to the participants that it is worthwhile to invest time and effort in 
participating. At this stage there are no second chance, i.e., there is no chance to 
come back for a second try after a failure. Every outcome that can be perceived as 
failure by some modeling participants will significantly hamper the future modeling 
efforts. Preparing for the first session is therefore of utmost importance. 

The objective is to plan a specific modeling session, i.e., to set its overall 
objective and questions to be addressed (information set 8 in Fig. 9.1). Existing 
models produced in previous modeling sessions of the project or earlier projects in 
the organization and/or other supporting information might also be analyzed. The 
initial list of relevant domain experts (information set 6 in Fig. 9.1) should be 
analyzed and candidates to involve in the modeling session should be selected 
(information set 9 in Fig. 9.1). 

The modeling facilitator usually needs to obtain additional information to learn 
more about the organization and the background of the problem at hand (Process 
4 Gather and analyze background information). Some of this information can be 
gathered from documents, e.g., policy documents. Also, essential enterprise data, 
e.g., balanced scorecard data, can also be useful. However, the most powerful 
instrument in planning for the session is interviewing the domain experts that are 
selected to participate in the modeling sessions. 
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The candidate modeling participants (information set 9 in Fig. 9.1) are 
interviewed individually in order to learn more about their views on the problem 
at hand (information set 11 in Fig. 9.1) and to assess the participant’s potential 
contribution at the modeling session (information set 12 in Fig. 9.1). A benefit for 
the candidate is that he/she is able to learn about the project and the upcoming 
modeling session in advance. In some projects it is beneficial to interview more 
people than the participants to be involved in the modeling sessions, because this 
allows the project team to learn more about the organization and, indirectly, to 
spread the word about the project and the coming change in the organization. 



9.4.1 Setting the Goals for the Session 



A modeling session is often one instance of series of modeling sessions, which all 
have their own goals, that are intended to contribute to the overall modeling project 
goal. The important thing here is that there is a goal for each modeling session. Just 
gathering a number of people in a room and starting modeling without a clear goal 
for the session and a plan for the flow of activities within a session will in most 
cases be disastrous and a waste of effort and resources. 

Setting the goal for a modeling session is part of the planning for the overall 
modeling project. It should be clear what should be produced in the session, which 
other project results that are input to the session, and how the result of the modeling 
session is intended to contribute to the overall project. 



9.4.2 Selecting the Right Domain Experts to Participate 
in the Seminar 



Domain experts should be familiar with the problem assigned to the project. 
Sometimes it may be beneficial to have both the “producer” and the “consumer” 
side represented to broaden the view. In some stages of the project, it may be 
necessary to associate specialists in certain areas to the project. These specialists 
may have the role to suggest organizational or IT solutions to satisfy specific goals 
stated (e.g., reengineering of some business processes, or development of some 
types of IT solutions). 

Who the right domain experts are depends on the goal of the session and which 
models that are to be produced. For example if a goal model is to be developed the 
right domain experts are those who are directly involved in, or have knowledge of, 
decision-making and goal formulation at the pertinent level of the organization, 
whether it be operational or strategic. If the goal is to restructure a process it may 
not require involvement by formal decision-makers. In all situations, however, it 
may be necessary to change members of a group as the discussions and models 
move from one area to another and require people with different knowledge. 
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9.4.3 Composing the Modeling Group 



The composition of the modeling group, i.e., the participants in a modeling session, 
is instrumental to the achievement of the goals for the modeling session. It should 
therefore be carefully composed based on the goals for the session. It is highly 
desirable that modeling experts have a strong influence on the composition of the 
modeling group. Otherwise the members of the modeling group will not be able to 
take full responsibility for the results of the modeling session. 

An ideal modeling group has the following characteristics: 

• The knowledge represented in the group covers the full scope of the problem 
domain as well as detail and overview. 

• The group is authorized to have an opinion about the problem at hand and to 
suggest a suitable solution to the problem. 

• The number of modeling participants is 4-8. 

• The group consists only of people that are expected to actively contribute to the 
modeling work. 

• The group consists of people without personal animosity between themselves. 

The ideal number of participants is 4-8. If there are less than four people the 
discussions tend to become less productive because the number of viewpoints 
becomes too small. If the number of participants exceeds eight some individual 
participants often tend to become less active. It also becomes difficult for the 
facilitator to manage the group process. Having more than ten people in a modeling 
group may work if the facilitator is very experienced and the plan for the session 
allows the facilitator to manage the session in a rather strict way. Alternatively, two 
modeling facilitators can support each other during the session and take turns as 
facilitator and observer. In such situations it is a good idea to plan for frequent short 
breaks to enable the facilitators to refocus and remedy any problems. 

The “direction” of the analysis, i.e., if the analysis concerns the current state of 
affairs or the future state, also defines requirements for the group’s composition. 
People deeply involved in a process can often describe the current state very well. 
However, when moving towards the future state, a different type of domain experts 
may be needed, i.e., visionary and creative people who are able to look at the 
process from a more holistic perspective e.g., how it relates to other processes and 
changes outside the organization. 

When composing the group it is essential to make sure that the domain experts 
will be given sufficient time to participate in the session. This is related to the issue 
of resources, in particular with regard to management support and time resources. 

Another aspect to make sure is that the domain experts participate with the 
intention of actually contributing to solving the problem at hand. For example 
having people in the group who are there to learn or observe will hamper the 
modeling process. “Everyone contributes!” should be the motto of a modeling 
session. 

The status or rank of certain stakeholders can also restrict the possibilities of 
composing a group that represents the best available competency. Some people may 
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sometimes falsely be considered highly competent both by themselves and others. 
To exclude such persons can sometimes be difficult. 



9.4.4 Interviewing Domain Experts 

Before planning for the modeling session it is strongly recommended to interview 
the domain experts individually. In most cases, one hour is a reasonable amount of 
time to spend on the interview, at least to begin with. In preparation for follow-up 
modeling sessions it may be necessary to carry out additional shorter interviews, if 
deemed necessary for preparing a session properly. 

The domain experts need to be prepared for what will happen during the session. 
This is particularly critical in organizations where the employees are not used to 
modeling in general and particularly to modeling in a group session. Lindstrom 
(1999) recommends that before the modeling session each individual modeling 
participant has to: 

• Understand the goal of the modeling session, 

• Agree upon the importance of this goal, 

• Feel personally capable to contribute to a positive result, and 

• Be comfortable with the rest of the team (including the facilitator). 

There are several goals with these interviews. They fall into three categories related 
to the problem at hand, the motivation of domain experts, and the group process. 

9.4.4.1 Goals Related to the Problem at Hand 

In order to prepare the modeling session in terms of issues to cover, driving 
questions, etc. the modeling expert needs to understand the views of the modeling 
participants regarding the problem, particularly, focusing on goals and possible 
obstacles to achieve the goals. Their views regarding how other stakeholders might 
think about the problem at hand are also important. This might reveal potential 
conflicts of interest and also personal animosities between stakeholders and stake- 
holder groups. If resolution of potential conflicts of interest is essential for solving 
the problem at hand, driving questions can be posed to the group during the 
modeling session, in order to make the conflict surface. However, bringing personal 
conflicts to the surface during a modeling session should be avoided. 



9.4.4.2 Goals Related to the Motivation of the Modeling Participants 

In order for the goals of the modeling session to be accomplished, the group process 
should have the highest possible quality so as to capitalize on the fullest potential of 
the competencies in the group. Therefore, one goal is to prepare the domain experts 
with regard to what will happen during the modeling session and why. It is also 
necessary that they understand in what way their particular competency contributes 
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to the goals of the session and of the project, i.e., why they are important. This 
clarifies what is expected from them during the session and motivates them to 
participate actively. To ensure motivation, the attitudes of the domain experts 
towards the modeling method and the participative approach should also be 
investigated. 

9.4.4.3 Goals Related to the Group Process 

The personalities in a group govern how the facilitator runs the modeling session. 
The facilitator will e.g. need to neutralize dominant persons and to encourage more 
introvert persons in order to accomplish full and consensus-driven participation 
from everyone. The facilitator will also need to ensure that the models produced are 
the result of consensus between the views represented in the session. Therefore, the 
modeling expert/facilitator will try to understand as much as possible of each 
individual’s personality during the interview. She/he will then be better prepared 
to facilitate the communication between the members of the modeling group. 

Below we suggest a sample of interview questions assuming a company named 
COMP, a division of the company named DIV, and a particular function of DIV 
named F. It is assumed here that the purpose of the project is to analyze F and 
suggest different possible improvements. 

After an initial round of mutual presentations, the modeling expert should 
explain the role of the interview and what will happen in the modeling session. 
Here it is important to pick up any signs of the domain expert feeling uncomfortable 
and discuss it up front, e.g., starting by saying: “I see that you are a bit uncomfort- 
able with what I say. Can you comment?” In general it is important to make it clear 
that the information given by the domain expert will only be used to prepare for the 
session, e.g., for formulating driving questions. It is unprofessional to make 
remarks in the modeling session about who said what in the interviews. The 
following questions about the problem at hand could be considered, using our 
example: 

• How would you describe the function F, its role, and current activities within 
DIV and within COMP? 

• Describe some, in your opinion, important issues within F to be addressed in the 
next 3-5 years. 

• Describe some problems currently experienced by DIV with the function F. 

• Give some long-term as well as short-term goals of the function F. 

• What makes F a necessary function within DIV? 

• What are, in your opinion, the current strengths and weaknesses of function F? 

• Which opportunities exist in the area of F? 

• Which external constraints would you like to mention regarding F? 

• Which external trends may influence the operation of F? How? 

• Which management should be particularly concerned with the operation of F? 

• Which important decisions, with long-range consequences, will we have to 
make within a year regarding F? 
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• Do you see any problems in carrying out these decisions? 

• Which opinions do you think other stakeholders could have about the problems 
of F? 

• What should we not talk about at the modeling session? 

The interviews give the project management and the facilitators an improved 
view of the persons who will participate in the modeling sessions and of their 
visions, problems, hopes, prejudices, and fears. This gives the facilitator a possi- 
bility to plan how to start the modeling session, how to conduct it, and how to 
handle possible upcoming situations. The interviews may give some hints on 
organizing the first modeling session depending on situations and opinions revealed 
in the interviews. 



9.5 Prepare Modeling Session 

A detailed plan for the modeling session (information set 14 in Fig. 9.1) is 
elaborated by analyzing the background material and findings from the interviews. 
This plan should include specific objectives of the modeling session, specific 
questions to be addressed, preliminary set of enterprise models to be developed 
(e.g., goal models, concepts models, actor models), a set of driving questions for 
starting the discussion, and the expected level of model quality. The modeling 
facilitator should also assess various risks and scenarios of how the modeling 
session might develop. For example what are the topics that the participants will 
not talk willingly, what are the topics that might lead the discussion astray, what can 
cause conflicts, and how to act in case of a conflict. This should be done in 
collaboration with the problem owner and project leader. The practicalities of the 
meeting (information set 13 in Fig. 9.1) should also be organized, which includes 
location, agenda, travel plans, etc. 

The first modeling session should be organized in a way that promotes concen- 
trated work. This may be achieved by convening in a special room not usually used 
by the participants or even at other premises, e.g., a conference facility. Such a 
choice of location may provide a more relaxing atmosphere and make interruptions 
unlikely. Needless to say, mobile phones should be switched off. 

Apart from four to eight participants, only a limited number of others should be 
present: 

• One or two facilitators. The number depends on the perceived complexity of the 
issues to be discussed as well as the number of participants. 

• The modeling project leader as an observer who needs an overall knowledge of 
the modeling work 

• A secretary as an observer with the following tasks: 

- To take care of the practicalities of the plastic sheet, arranging coffee 
breaks, etc. 

- To document the process of the modeling session. 
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9.5.1 Setting up the Room for Modeling 



The room must contain at least one large (3 m x 2 m) wall clear of all decoration, to 
attach a plastic sheet on. There should be precisely enough chairs and tables for the 
participants. It should be large enough so that nobody could “hide” or make him or her 
unavailable. There should not be any distractions such as refreshments, telephones, etc. 

9.5.2 Equipment 

In the room there should be the following equipment: 

• At least one plastic sheet 

- Thick 

- Two meters wide, on a roll 

• Pens 

• Non-permanent to enable erasure from plastic sheet 

- Medium point 

- At least one for each participant 

• Paper 

- Preprinted with components’ names 

(a) Each component type has a different color to enable easy identification 

(b) An A4 page cut into four quarters gives a satisfactory size 

- A4 papers of different colors 

• Wet rag 

- To wipe off pen drawings from the plastic sheet 

• Adhesive putty 

- Two small blobs attached to the back of each piece of paper ensure that these 
stay attached to the plastic sheet when required while allowing them to be 
easily transferred 

• Scissors 

• An overhead projection machine or a beamer connected to a laptop 

- For presenting introduction material and other information necessary to run 
the session 



9.6 Conduct Modeling Session 

The modeling session is conducted according to the plans made initially. Here we 
will not describe details of how a modeling session is conducted. Recommendations 
of what to do and what not to do are included in Sect. 9.5 and, for example, in Stirna 
et al. (2007), Sandkuhl and Lillehagen (2008), Jprgensen (2009), Stirna and Persson 
(2009), and Willars (1999). The tangible outcome of the modeling session are the 
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models produced (information set 16 in Fig. 9.1) and an additional list of actions for 
implementing the decisions made during the modeling session (information set 
15 in Fig. 9.1). Additional intangible outcomes of modeling are participants’ 
improved understanding of the problem area and a firmer commitment to the 
decisions made (Persson 2001; Lindstrom 1999). 

After the modeling session it is recommended to write minutes of the meeting 
(information set 17 in Fig. 9.1) which includes the models as in the state were 
produced at the modeling seminar and action list. At this stage the models should 
not be more refined because the main purpose of this activity is to send notes to the 
participants, which might also serve as a reminder of the actions that they have 
agreed to be responsible for. 

In the following, we provide a set of practical tips to help the modeling team to 
effectively carry out the session. 



9.6.1 Introducing the Session to the Participants 

A short introduction is to be given of each of the following: 

• All those present 

• The agenda of the session 

• The topic(s) for discussion 

• The ground rules for modeling 

These are necessary since these are not self-evident and are necessary for 
maximal productivity. They explain the accepted social interactions and means 
of furthering creativity: 

- Everybody participates — no spectators 

- Everybody contributes constructively — differentiate between person and 
subject matter 

- Everything of importance is written down — talk disappears, the plastic sheet 
counts 

- Better overexplicit than implied 

- Better half-done here and now than completely brilliant next week 

- Write complete sentences rather than keywords 

- Listen to each other and think individually 

- Build further on each others thoughts 

- Strive for balance and consensus in the result 

- Search after missing threads of thought 



9.6.2 Stimulating and Structuring the Modeling Activity 

The goal of EM is, of course, not only the Enterprise Model as such. The Enterprise 
Model is just a description and representation technique. To obtain an improved 
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understanding, to solve problems, and to develop the enterprise we should be 
directed by a critical and analytical study of the Enterprise Model and its internal 
relationships. This should be based on good understanding of the principles of EM 
as they have been presented previously in this book. It is particularly important that 
relationships between sub-models of 4EM are used as drivers in this work. This 
may be achieved, to some extent, with the aid of driving questions of the following 
type: 

• Is each goal supported by a process in the Business Process Model? If not, why 
not? 

• Should we then introduce such a process? 

• Who in the Actors and Resources Model should be responsible for this process? 

• Are they already responsible for a similar process or is there someone else? 

• Should we invest in a new resource to help us run this process? 

• Does this resource need a new or improved information system? 

• Can we identify in the technical and requirements model, the requirements for 
the information system? 

• Are there business rules that may put constraints on the requirements? 

• Do we have a common enterprise definition of what these constraints and 
requirements mean, in the Concepts Model? 

By searching for relationships and inconsistencies, and discovering gaps, we can 
increase our knowledge and understanding of the enterprise. The search for knowl- 
edge must be made on an individual and group basis in the context of the situation, 
given the particular intentions of the participants. 4EM will help you in the right 
direction, by giving you the graphical, structured representation technique in the 
form of the Enterprise Model, making the cognitive process of analysis easier. 
Hence, the lists of driving questions mentioned in previous sections are not com- 
plete, but only examples that should be further expanded when applicable. 



9.6.3 What to Avoid 

There are many pitfalls when one is involved in the communication of ideas 
between humans, which is what we are dealing with. In the specific case of 4EM 
these include: 

• Avoid beginning modeling with long explanations of abstract concepts. 

• Begin with well-known practical or physical activities, processes, or goals. 

• Avoid, if possible, creating unstructured models. This does not mean that the 
initial model must always be structured. It can be done in such a way that at first, 
modeling components are simply grouped together according to some criteria 
and relationships are introduced later in the modeling session. In fact, the session 
often involves idea generation and restructuring iterations. 
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• Conduct additional restructuring and clarification activities as soon as possible 
after the modeling session; otherwise a lot the information inherent in the 
unstructured model will be forgotten. 

• Avoid having few-worded formulations of modeling components that are not 
intuitively understood. 

• Do not have goals that do not contribute to the overall objectives of the 
enterprise. 

• All goals must be connected so that they contribute to each other. No loose ends 
should exist. 

• Avoid composite statements that have many in and out relationships so that they 
do not allow for easy understanding and analysis. 

• Try to break down statements to the last point at which they are relevant to the 
issues at hand. 

• Avoid detailing attributes before an overall conceptual structure is established. 

• Not all attributes are relevant. 

• Do not verbalize what is apparent in the model. 

• Avoid having concepts that you are unsure why you have them. 

• When choosing particular words, confusion and missing concepts may be 
avoided by creating new words. 



9.7 Analyze and Refine Models 



Enterprise Models created at a modeling session usually need further refinement in 
terms of presentation and layout, as well as content. The result of the modeling 
session should also be analyzed with respect to the objectives of the session and the 
project. This either leads the project team to a conclusion that the expected result is 
achieved and can be presented to the organization (information set 18). Otherwise 
the team identifies a set of issues for further development and modeling (informa- 
tion set 19 in Fig. 9.1) and proceeds with planning subsequent project activities 
(process 2 in Fig. 9.1). In many cases information sets 18 and 19 are reports of the 
project activities. 

After the first modeling session, the modeling experts document the models 
using a computer-based tool (Chap. 5). The first session is often mainly a brain- 
storming activity. Hence the state of the model is such that: 

• It is lacking a clear structure, making it difficult to get an overall picture. 

• There are redundant components, for example, there may be two goals stating 
roughly the same thing. 

• There may be missing components 

• Relationships are lacking showing how components are connected to each other 

• The terminology written by domain experts may be ambiguous. 

The overall objective of structuring and analyzing the results of the first session 
is, therefore, to “make sense of the mess.” It is to systematically go through all the 
models, components, and relationships and make them presentable as a basis for 
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further deliberation by the participants in the following session. That is, by clari- 
fication, abstraction, structure, simplification, derivation, deduction, and induction. 

To achieve progress in terms of structure and clarity of the models the following 
strategies can be useful: 

• Organize the model to make it more readable 

For instance, crossing arrows should be reduced and grouping of components 
can be made. 

• Introduce relationships 

The models are given meaning by drawing relationships so that, if possible, all 
components in the models are connected to at least one more component. 
Implicit, undesirable, or overlapping relationships may be discovered and 
adjusted. Missing components may be discovered. Since the analysts may not 
have the requisite knowledge, it may be necessary to consult with stakeholders to 
get a better understanding of the relationships. 

• Clarify terminology 

Concepts, terms, and abbreviations that are unclear or ambiguous need to be 
clarified. Domain experts often need to be consulted to explain and define 
concepts. 

After the models produced in the modeling session have been documented it is 
time to make sure that they live up to expectation and correctly capture what has 
been modeled, i.e., they need to be accepted by the modeling group that participated 
in the session. This can be done in at least two ways that we discuss here: by 
interviewing stakeholders and by organizing walk-through sessions. 

Interviewing stakeholders may seem as a feasible way ahead, since it is easier to 
schedule an interview with a person than to organize a session with several people. 
Particularly if the people concerned are managers. However, this often proves to 
cause problems later on. One important purpose of having a walk-through session 
is, like in participative modeling session, to ensure that different views on the 
problems are represented in the same room, allowing for quality enhancing discus- 
sions between domain experts. 

At the walk-through session, the analysts present work done since the first 
session and the rationale behind the work and enhance the models. The session 
should aim to achieve all the following: 

• Review the work from the first session 

• Make corrections and/or additions to the models and descriptions 

• Narrow the field of discussion and specify the domain 

• Expand previous models 

• Suggest further work and future directions 

The resulting models from the first modeling session should be presented to the 
modeling group precisely as it was. To present the refined model to the modeling 
group requires careful planning. The group must be able to trace the results of their 
efforts, from the original plastic sheet model through the analysis stage to models 
presented at the next stage, the walk-through session. They must be able to 
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recognize what they have done in the modeling session. A description must 
acknowledge and give credit to the first session by a verbal description of the 
results. 

At this stage, models produced by computerized tools have replaced models on 
plastic sheets. Since it is impractical for up to eight people to gather around a 
normal sized computer screen, the model should be projected using a beamer. As 
well as the computerized presentation equipment required, all the equipment 
necessary for modeling as mentioned in Sect. 9.5 is also needed. This may entail 
the use of a larger room or possibly two rooms, one for projection and one for 
modeling. 

A large screen allows all the participants to view the computer-generated 
models. In theory, continued modeling directly on the screen together with a tool 
expert is possible. However, this is not advised as the focus of the group may move 
from the issues to be discussed to small improvements and/or technical finesses of 
the modeling tool. 

The presentation is a balancing act. The analysts must actually do an analysis, 
while at the same time not discarding the group work that has been. When 
interpretation, change, or deletion is done, it must be explained and justified. This 
is to ensure that the group will continue to be motivated to contribute. Otherwise, 
credibility of the analysts and eventually the models is lost. 

The results of the first walk-through should be a validation and adjustment of the 
models being discussed. 

Sometimes the modeling project is very small. In fact, sometimes one modeling 
session is enough. In most cases more sessions are needed to achieve the modeling 
project goals. Then the process starts all over with preparations and carries through 
to validation of models. 



9.8 Present the Results to Stakeholders 

The modeling project ends with presenting the results to the problem owner and 
relevant stakeholders. A part of this presentation is decision making on how the 
results should be implemented or taken up by the organization. It might also be that 
the stakeholders identify issues that are not resolved and require further develop- 
ment (information set 19 in Fig. 9.1). 

The EM process we have outlined ends when the problem owner and the 
involved stakeholders feel that they have a result that can be implemented. In 
practice the EM project results will most likely serve as input for another develop- 
ment project, including an IT or IS development project. 

The EM process described in this section may appear easy to conduct on the 
outset. In reality, however, there are many challenges to succeed and pitfalls to 
avoid, particularly in the project preparation phase (processes 1-6). Much of this 
knowledge is related to organizational and social issues and hence is not easily 
formalizable. 
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9.9 Change Management in Enterprise Modeling Projects 

Enterprise modeling projects, particularly in development situations, typically go 
through a series of modeling sessions where modeling of the current state of the 
problem is followed by definition of change requirements. These change requirements 
are the basis for modeling future state models, which are then used as “blueprints” for 
development of, for instance, business processes and/or information system. 



9.9.1 Modeling and Analyzing the Current Situation 



As a rule, all 4EM sub -models are required to comprehensively model the current 

situation. Each sub-model is developed in an iterative process, which may include 

the following steps: 

• Modeling starts in a moderated modeling session. Additional sessions may be 
required for extensive processes or structures 

• The results of the session(s) are documented in the chosen modeling tool 

• The models created with the tool are presented at a workshop with the partici- 
pants from the initial modeling session(s) and checked for factual accuracy 

• The models are enhanced in workshops of this kind until they reach a state of 
elaboration that the modeling group and the project manager are comfortable 
with moving onwards to implementation of the model. 

• The relationships between the various sub-models are reviewed and expanded if 
necessary 



9.9.2 Setting Out Change Requirements 



Modeling the current situation will have identified the processes, structures, sys- 
tems, or rules that must be changed in order to remedy the problems that have 
occurred. There often are several possible ways how changes can be made, and 
conflicts between enterprise goals often become clear in the goal/problem model. 
This means that the urgency and priority of the set goals must be decided here 
before creating a future state model, and an agreement must be reached as to which 
of the viable potential changes should be chosen. If it is not possible to decide which 
potential changes are the most suitable ones based on the goal priorities, multiple 
versions should be developed in the stage of future state modeling. The result of this 
step, which generally takes place in a joint workshop involving a representative of 
the commissioning party, the project leader is to obtain an agreement as to which 
versions should be developed in future state modeling. 
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9.9.3 Creating Future State Models 

The future situation that should be brought about in order to remedy the observed 
problems is generally defined based on the actual situation. This step therefore 
mostly involves refining the models of the actual situation so that they describe 
future processes, structures, systems, rules, and concepts. Models need only be 
completely recreated in the event that changes are required due to the introduction 
of completely new processes or structures in the enterprise, or due to radical 
alterations to processes or structures. 

This step produces a description of the enterprise’s future situation in the form of 
a future state model. The future state models can then be used as a “blueprint” for 
organizational change or as part of the specification of requirements for any 
necessary software developments. 




Chapter 10 

Supplying the Modeling Project 
with Competent Modeling Experts 



Human knowledge and competence is a critical resource for achieving the goals of 
EM. There are two reasons for this: 

- Models contain human knowledge about an organization in its current or 
envisioned future state. We need domain experts who contribute this knowledge. 

- The knowledge of domain experts has to be captured and structured in enterprise 
models, which contribute to the EM goals. We need modeling experts who are 
able to do this. 

The competency of the modeling expert is a critical resource in EM application. 
Modeling experts are responsible for the effective adoption of a chosen method and 
for the project to reach its goals using the assigned resources. In the following, the 
necessary competency of experts in a modeling project is described. 



10.1 Core Competences in Relation to EM Project 
Activities 

Figure 10.1 depicts three levels of method expert competence that are developed 

with growing experience. 

• Ability to model, which means that a person is able to construct an Enterprise 
Model which is syntactically correct according to the used EM language and that 
the model in a reasonable way reflects the domain and problem in question. 

• Ability to facilitate modeling sessions, which means that a person is able to lead 
a group of domain experts in creating/refining an Enterprise Model and to do it in 
such a way that the group’s knowledge and abilities work together to create a 
high quality model. 

• Ability to lead EM projects towards fulfilling their goals and making the best of 
the project resources. 
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Fig. 10.1 Core 
competences of EM in 
relation to experience 
(Persson 2001) 




The list of relevant competences that are useful for acting at each level can 
potentially be very long. We claim that in order to target the main challenge of the 
EM process, which is to produce an EM outcome that is fit for its intended use, we 
need to define a set of essential core competences that target the quality of the 
outcome of EM. In the following we describe the core competences that our 
research has yielded so far. They fall into two distinct categories: 

1. Those related to modeling itself, i.e., the ability to model and the ability to 
facilitate participatory modeling session. These competences are at the heart of 
modeling and 

2. Those related to setting up and managing EM projects. 

10.2 Competences Related to Modeling 



The ability to model involves making use of the chosen EM language to create and 
refine enterprise models. The resulting models should reflect the discussion in the 
modeling session and focus on the problem at hand. Knowing how to use modeling 
tools for documenting and analyzing the modeling result is also included in this 
ability. One important, and sometimes neglected, aspect is the ability to create a 
readable model, because they tend to become large and graphically complex. 

Since we advocate a participatory approach to EM, the ability to facilitate a 
modeling session is essential. Facilitation is a general technique used in group processes 
for a wide variety of purposes, also within EM (see further, e.g., Zavala and Hass 
(2008) and International Association for Facilitators (IAF) http://www.iaf-world.org). 
This ability is very much based on knowledge about the effects of modeling, the 
principles of human communication and socialization (especially in groups), as well as 
the conditions of human learning and problem solving (cognition). For Enterprise 
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Modeling, some of the more important aspects of this competence are to condense and 
capture important ideas, to pose questions that trigger discussion, to listen, to summa- 
rize and generalize, as well as to drive the discussion towards fulfilling the goals of the 
EM session. 

For both of these abilities we want to highlight the fact that the competence 
requirements are quite different if EM is used to capture the current situation 
compared to designing a future situation. In the latter case the ability of the EM 
practitioner will be geared towards drawing out the creativity of the domain experts 
and to guide that creativity towards the goals of the session. 



10.3 Competences Related to Managing EM Projects 



In order for the models to be fit for their intended use, the EM practitioner needs the 
ability to select an appropriate EM approach and tailor it in order to fit the 
situation at hand. Sometimes that choice is restricted by the requirements of the 
context of use, as, e.g., is the case when EM is used in an IS development project 
that uses a particular method and tool- set. In other cases the choice of an EM 
approach is up to the EM practitioner. Based on her/his knowledge about the 
problem at hand, the requirements on the EM result, the preferences and modeling 
skill level of the modeling group, and the context in which EM will be used the EM 
practitioner will have to choose an appropriate approach. The professional EM 
practitioner will have a “tool-box” of potential methods for different purposes that 
she/he is able to use. Independently of whether the EM practitioner has the choice 
of approach, the approach often needs to be tailored to fit the situation at hand and 
she/he will then need to be able to assess the consequences of any changes made to 
the approach. 

As discussed before, in participatory EM the ability to interview involved 
domain experts before the EM session is critical. In this situation the social skills 
of the EM practitioner are essential, such as, e.g., ability to listen, ability to read 
body language. In a discrete way the EM practitioner needs to ask the domain 
expert what should be talked about in the modeling session and also try to find out 
what topics should be avoided and why. 

For EM to have effect in its context of use, it needs to be focused towards a 
particular goal or problem. This pertains both to the overall EM project level and to 
each EM session. The ability to define a relevant problem that is feasible to model 
based on the information that the EM practitioner can obtain is, therefore, impor- 
tant. This ability is very much related to the ability to interview domain experts. In 
this ability the capacities to conceptualize, to generalize, and to assess the relation- 
ships between different problems are included. An essential aspect of defining the 
relevant problems is the ability to spot hidden agendas, which builds both on the 
practitioner’s previous experience but also on her/his social skills and ability to 
“read between the lines” in a conversation. Unidentified hidden agendas can 
potentially cause problems later on in the EM project. Assessing the complexity 
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of a problem is also part of defining a problem. Problem complexity is a heavy 
influence on the planning of the project both in terms of activities and resources. It 
can be argued that it is impossible to define a clear problem on the outset and that it 
will change as the project proceeds. This is true, but in order for the project to 
become operative at least a “working problem” is needed. 

In planning an EM project and an EM session, the ability to define requirements 
on the results are essential in order for project/session goals to be achieved. These 
requirements relate to the models that are to be produced as well as what is to be 
achieved by these models. Sometimes the requirements have to do with the process 
itself. For example by involving certain stakeholders and having them listen to what 
other stakeholders have to say in a participatory EM session, certain change 
decisions can be made less dramatic for the organization. The EM practitioner 
should also keep in mind that the models produced is the tangible result of 
modeling, but equally important is the intangible result — participants’ changed 
thinking and understanding of the problem. 

The ability to establish a modeling project is critical in order to create the most 
beneficial conditions for the EM project. Favorable conditions will increase the 
chances of obtaining the desirable effects of EM. Conditions involve resources in 
terms of time and competence (domain as well as EM practitioner competence) as 
well as authority for EM project participants to act freely and make decisions within 
the project definition. This ability is essential in any project. 

The result of modeling will be used for a specified purpose. In order for that 
purpose to be fulfilled the users of the result need to understand it and its implica- 
tions. This means that the modeling practitioner will have to present it in oral and/or 
written form to them. Depending on the target audience, certain aspects of the result 
will need to be emphasized or toned down. For example presenting project results to 
a group of managers, the detailed data structure of the supporting IS can be omitted. 
This requires an ability to adjust a presentation of project results and issues related 
to them to various stakeholders. 

An EM project is a signal to the organization that change of some kind is 
imminent. This means that various stakeholders will try to influence the EM 
practitioner so that their own goals will be those of the EM project. To navigate 
between the wishes of various stakeholders while upholding the EM project goal is, 
therefore, a critical competence. More about the challenges involved in tackling this 
problem can be found in Kaarst-Brown (1999). 

EM projects typically deliver a solution to a business problem. The solution 
usually consists of an organizational design proposal (which might include an IT 
solution) reflected in Enterprise Models. A partially intangible outcome of the EM 
project is the supporting set of decisions and commitment to implement the 
solution. Example issues to consider are: would the solution appear to be inappro- 
priately bureaucratic, democratic, authoritative; what kind of implementation activ- 
ities are needed, etc. An ability to assess the impact of the modeling result and the 
modeling process in the organization is therefore needed to drive the modeling 
effort towards a solution that has a high probability of being implemented within 
the organization. 
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Table 10.1 Matching of EM process steps to core competences (Persson and Stirna 2010) 



Process 



Ability 


PI 


P2 


P3 


P4 


P5 


P6 


P7 


P8 


P9 


P10 


To model 














X 




X 




To facilitate modeling sessions 














X 








To interview involved domain experts 










X 












To define a problem 


X 




X 






X 






X 




To define requirements on the results 


X 


X 


X 
















To establish a modeling project 


X 




















To adjust presentation of project results 












X 








X 


To navigate between the wishes of 
stakeholders while upholding a defined 
project strategy 


X 


X 






X 




X 






X 


To assess the impact of the modeling 
result and the modeling process in the 
organization 


X 


X 








X 






X 


X 



In Table 10.1 the core competences are summarized and mapped to the process 
steps defined in Fig. 9.1. 



10.4 Different Purposes of EM Require Different 
Competencies 

In this section we describe how the core competencies described in the previous 
section come into play depending on the purpose of EM. 



10.4.1 Develop Visions and Strategy 

Ability to model , including assessing and improving model quality according to the 
EM purpose. In addition to the core abilities to model and to facilitate modeling 
sessions, this EM purpose also requires specific modeling abilities to model on a 
high level of abstraction where initially the enterprise model is not internally 
connected and may appear to be consisting of “small islands.” The main challenge 
here is to guide the modeling work towards a certain direction. This might be hard 
because a part of strategy development is to allow the group to explore different 
options to a certain degree. The facilitator, however, needs to have the ability to see 
a certain “path” in the models and steer the modeling participants from drifting off 
course, for instance, by discussing peripheral problems and defining goals that are 
plainly unrealistic. This situation requires the practitioner to deal with a large 
degree of uncertainty while demonstrating confidence to the participants in the 
group. 
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Regarding competencies related to setting up and managing modeling projects 
the following specifics should be paid attention to: 

Ability to select an appropriate EM approach and tailor it in order to fit the 
situation at hand. For strategy development there exist a number of suitable 
development approaches that the modeling practitioner needs to be reasonably 
knowledgeable about. The modeling participants might often be familiar with a 
specific modeling language and notation. Importing a strategy development 
approach into EM in most cases implies defining new “inter-model” links with 
the existing components in the enterprise model and/or defining synonyms among 
modeling components. This requires deep knowledge about the meta-models and 
intentions of the involved methods. 

Ability to define a relevant problem. The ability to define a relevant problem 
goes hand in hand with the ability to facilitate. The problem might be defined 
relatively vaguely, e.g., to find the real problem. Nevertheless the EM practitioner 
should have the ability to define at least general boundaries for it. 

Ability to navigate between the wishes of various stakeholders while upholding 
the EM project goal. Deciding on the direction of an organization influences an 
organization more than short-term decisions. Therefore, the risk of having to deal 
with various hidden agendas from stakeholders is imminent. Also, these stake- 
holders often have an influential position in the organization. This means that the 
modeling practitioner needs to be listening and diplomatic while demonstrating that 
she/he is the person in charge of the EM project. Taking this role requires experi- 
ence and knowledge about how organizational cultures function as well as patience, 
an agreeable personality, and a firm but pedagogical way of communicating. 

Ability to assess the impact of the modeling result and the modeling process in 
the organization. Being able to assess the impact of a vision or a strategy requires 
some experience from both successful and unsuccessful processes of implementing 
strategies, since the degree of uncertainty can be quite high. 



10.4.2 Design/Redesign the Business 



Ability to model, including assessing and improving model quality according to the 
EM purpose. To fulfill this purpose, the EM practitioner should be able to assess 
that the models have enough quality to be implemented under the conditions that 
exist or will exist in the business at hand. This requires some previous experience 
from being involved in, e.g., implementing processes in an organization. One 
important aspect here is to be able to assess not only the practical implications of 
change but also the cultural implications of change. 

Ability to facilitate participatory modeling sessions. When designing/ 
redesigning the business one of the main challenges is to avoid polishing the current 
way of thinking and working. The EM practitioner should be able to support the 
creativity of the group while maintaining a critical view on the resulting models. 
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Specific competencies related to setting up and managing EM projects are as 
follows: 

Ability to interview involved domain experts. Following the previous discussion, 
the EM practitioner should be able to assess the ability of potential modeling 
participants to think creatively and out of the box and to make sure that some 
people in the group are also “critical thinkers”. 

Ability to define requirements on the results. Often projects like these require 
that different types of models are developed. The EM practitioner should, therefore, 
be able to define how the whole project sticks together and how each model 
contributes to bigger picture. Changes in the target area of the project could also 
influence other areas of the business. This means that the requirements on the result 
must be related to an even bigger picture that constitutes the surrounding organi- 
zation and sometimes partner organizations. Requirements must be defined such 
that the result can be implemented afterwards. Putting this complicated “puzzle” 
together requires a high level of experience and skill from the EM practitioner. 

Ability to establish a modeling project. An important aspect of establishing an 
EM project with this purpose is to negotiate authority for change. Both the EM 
project leader (EM practitioner) and the modeling group/s involved must feel that 
they are authorized to make design decisions that take into account the goals and 
constraints of the project. This means that the EM practitioner must be able to 
identify which authorities are needed, identify the involved decision makers and 
negotiate the proper authorities. Sometimes it happens that decision makers go back 
on what they have approved, and then the EM practitioner will need to be able to 
either negotiate maintained authority or redefine the scope of the project. 

Ability to navigate between the wishes of various stakeholders while upholding 
the EM project goal. All processes that involve change will cause different kinds of 
resistance in the organization. Therefore, the risk of having to deal with various 
hidden agendas from stakeholders is highly possible. This means that the modeling 
practitioner needs to be listening and diplomatic while demonstrating that she/he is 
the person in charge of the EM project. Taking this role requires experience and 
knowledge about how organizational cultures function as well as patience, an 
agreeable personality, and a firm but pedagogical way of communicating. 



10.4.3 Develop Information Systems 

Ability to model. The specifics in relation to this purpose primarily focus on 
assessing and improving model quality according to the EM purpose of developing 
an IS. More specifically, the enterprise model should be created in such a way that it 
is possible to implement in a system. This might require increasing model formal- 
ity. In this context the EM practitioner should understand the use of the models in 
the IS development project, e.g., how Concepts Model can be used as input for 
developing a database schema. Ultimately, the EM practitioner should have some 
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experience from IS development projects, preferably from an operative point 
of view. 

Ability to facilitate participatory modeling sessions. This purpose requires the 
ability to guide the modeling effort in such a way that a balance between the IT and 
business aspects is ensured. If one of the aspects dominates the other, the resulting 
solution risks being unsuitable for the organization. 

Regarding competencies related to setting up and managing EM projects, the 
following specifics should be paid attention to: 

Ability to select an appropriate EM approach and tailor it in order to fit or be 
docked to the IS development process and its specific development methodology 
and (often) tools. In principle many modeling languages and tools can be used for 
this purpose and most often modeling language of one sub-model in the enterprise 
model can be replaced with another modeling language as long as the inter-model 
links remain intact. For example 4EM Goals Model notation in principle can be 
replaced with another similar notation, and Concepts Model changed to UML Class 
Diagram. The modeling practitioner should be able to perform such a method 
engineering task. 

Ability to define requirements on the results. Modeling practitioner should be 
able to assess how models are used in the IS development process and when the 
model is complete enough to proceed to IS development activities. 

Ability to establish a modeling project. This EM purpose means that EM is used 
in a IS development project and perhaps not seen as a project in itself, but rather a 
set of intertwined activities. The modeling practitioner should be able to understand 
the IS development methodology and design EM steps in a suitable way. 



10.4.4 Ensure Acceptance of Business Decisions 

For the EM purpose the main success criteria is that the decisions made during 
modeling and reflected in the model are accepted and taken up by the organization. 

Ability to facilitate participatory modeling sessions. The facilitator should make 
sure that the group reaches consensus and real decisions that can be implemented in 
the organization. Furthermore, the facilitator should also make sure that the partic- 
ipants perceive the enterprise model as documentation of the decisions and the 
decisions as real allocated to real people for implementation. 

Concerning competencies related to setting up and managing EM projects, the 
following are of relevance: 

Ability to select an appropriate EM approach and tailor it in order to fit the 
situation at hand. All kinds of modeling tricks can be necessary, including breaking 
the methodology rules, modeling notation, and using unconventional approaches. 
The modeling practitioner should be able to assess the impact of such actions on the 
modeling results and the process. 
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Ability to interview involved domain experts. This EM purpose might be asso- 
ciated with hidden agendas that need to be uncovered. Finding out how decisions 
are made in the organization and how they are implemented also is crucial. The 
modeling practitioner should have good listening skills because these issues can 
seldom be addressed with a straight question. 

Ability to define requirements on the results. In this case the acceptance and the 
consensus could be seen more important than the model quality. Hence, it might 
sometimes be purposeful accepting low model quality if the group agrees with the 
decisions made. 

Ability to navigate between the wishes of various stakeholders while upholding 
the EM project goal. This is particularly important because the project usually 
covers a broader group of stakeholders than is possible to involve in modeling 
directly. 



10.4.5 Maintain and Share Knowledge About the Business 

For this purpose it is important to understand that sometimes existing models are 
used as input and sometimes models are created for the purpose of depicting how 
the business is carried out. In the latter case the modeling is about capturing the 
current state of affairs and ways of working. 

Ability to model , including assessing and improving model quality according to 
the EM purpose. The models that are created for this purpose have a specific target, 
which is to convey a message and also to instruct a diverse group of stakeholders. 
This means that the understandability of models is essential, which in this case is a 
critical aspect of model quality together with correctness. For the EM practitioner 
this means that the ability to become knowledgeable about the characteristics and 
needs of the target groups is important. Listening and communication skills are 
essential here. 

The following specifics should be paid attention to concerning competencies 
related to setting up and managing EM projects: 

Ability to select an appropriate EM approach and tailor it in order to fit the 
situation at hand. In this case, the modeling language should either be familiar to 
the stakeholders or be simple enough to understand without prior knowledge of the 
language. The EM practitioner should have enough knowledge about modeling 
languages to be able to balance quality aspects such as correctness of the models in 
terms of state of affairs of the business with the quality aspect of understandability. 

Ability to define requirements on the results. This ability relates, again, to the 
understandability of models. Also, in order to be able to properly define the 
requirements, the EM practitioner should have some knowledge relating to orga- 
nizational learning. This is further discussed under the ability to assess the impact of 
the modeling result below. One important aspect of this ability is setting up for 
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maintenance of models, because the business changes and the models should 
change accordingly. This means that the EM practitioners need to be knowledge- 
able about different tools that can be used to document and maintain models as well 
as be able to set up a feasible maintenance process. More on what is needed to keep 
models “alive” is available in (Stirna and Persson 2008; Wesenberg 2011) and on 
using Active Knowledge Models in organizations see (Lillehagen and Krogstie 
2008). 

Ability to adjust a presentation of project results and issues related to them to 
various stakeholders. Presentation of the resulting models is one of the key issues 
for this purpose. Sometimes the models themselves may not be the best way to 
present the organizational knowledge and some alternative ways of presentation 
must be devised. Providing background information and connecting models to this 
can be one potential approach. Another approach could be to develop simulations 
based on the models. The ability to understand the conditions under which the 
models/information makes sense to the intended stakeholder groups is essential 
here. Pedagogical knowledge is also helpful, together with knowledge about how 
different media can enhance the message that is being conveyed. 

Ability to assess the impact of the modeling result and the modeling process in 
the organization. The ultimate desired impact of fulfilling this purpose is that 
organizational learning is created. To lead a modeling project with this purpose, 
the EM practitioner should preferably have some knowledge and experience from 
fields that address organizational learning, such as, e.g., Knowledge Management. 



10.4.6 Use EM to Analyze and Solve a Specific Business 
Problem 

EM projects with this purpose are usually quite short and compact in time, e.g., they 
should be done within a week. More about what happens in early phases of EM is 
available in (Persson and Stima 2010). For this purpose the modeling competencies 
do not have specific areas or concerns, but competencies related to setting up and 
managing EM projects have to include the following specific issues: 

Ability to select an appropriate EM approach and tailor it in order to fit the 
situation at hand. In this case simple EM languages and notations should be 
preferred because there will be no time to familiarize the participants with the 
modeling approach. We recommended using 4EM with relaxed notation. Also, 
using the approaches that the organization already has should be preferred. The EM 
practitioner should be able to find out what the organization has in terms of existing 
approaches and assess how it can be used in an EM project. 

Ability to interview involved domain experts. Interviewing needs in this context 
to follow a tight schedule, since time for planning is usually very restricted. The 
interviews should, however, not be done in a haphazard way, i.e., the EM practi- 
tioner should be able to follow a predefined interview script and keep the schedule. 
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Ability to define a relevant problem. Even in short projects such as these the 
problems put forward by the domain experts can be quite large and many. The 
modeling practitioner should be able to find the relevant problem/s in a cluster of 
problems. 

Ability to define requirements on the results. In this situation there are often very 
strict constraints in terms of time and other resources. For example there may only 
be time for one modeling session. This requires the modeling practitioner to be 
realistic in terms of what can be achieved and to communicate this to the problem 
owner, especially in cases, where the resource constraints put at risk achieving the 
expected result. 

Ability to assess the impact of the modeling result and the modeling process in 
the organization. Since the EM project happens so quickly in the organization, the 
difficulty is to make sure that someone will actually take up the result and imple- 
ment it. This needs to be addressed in the project negotiation and planning phase, 
for example, by inviting modeling participants that can support implementation. 




Chapter 11 

Adoption of Enterprise Modeling 



Organizations usually begin using EM within the context of a development project 
of some sort, where an outside vendor and/or consultant provides the method and 
tool usage competence. If an organization uses EM sufficiently frequent it may be 
motivated to develop in-house EM competence and to acquire and adopt an EM 
method. This chapter discusses the process of acquiring an EM approach. Acqui- 
sition of EM tools is addressed in Chap. 5. 

The chapter begins with a discussion about what it means to adopt EM in an 
organization, i.e., to support continuous improvement. Afterwards an overview of 
the adoption process and its different phases is provided. These are then addressed 
in turn. A short note on training of modeling experts is also included. 



11.1 Supporting Continuous Organizational Improvement 
with EM 



The reader is here reminded of the two main reasons for using EM: 

• To develop the business. This entails developing business vision, strategies, 
redesigning the way the business operates, developing the supporting informa- 
tion systems, etc. 

• To ensure the quality of the business, focusing on: (1) sharing the knowledge 
about the business, its vision, and the way it operates, and (2) ensuring the 
acceptance of business decisions through committing the stakeholders to the 
decisions made. 

In Chap. 9, EM as a project was discussed. Typical EM activities are summa- 
rized in Table 11.1. 

In this chapter we take one step up from EM projects and consider them to be 
part of an organizational strategy to use EM for supporting continuous 
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Table 11.1 Activities in EM 
(Stirna and Persson 2012b) 



Define scope and objectives of the modeling project 

Plan for project activities and resources 

Plan for modeling session 

Gather and analyze background information 

Interview modeling participants 

Prepare modeling session 

Conduct modeling session 

Write meeting minutes 

Analyze and refine models 

Present the results to stakeholders 



organizational improvement. The EM lifecycle can then be outlined according to 
the following steps, which is also depicted in Fig. 11.1. 

1 . Something triggers the need to investigate a potential change in the organization. 
This trigger can be a business opportunity, a challenge, a problem, or a symptom 
of a problem. A choice is made to use EM in the investigation and potentially 
also to design a change to business operations and/or the IT systems that support 
business operations. 

2. The EM project is initiated and executed according to the process described in 
Chap. 9. 

3. The implementation of the resulting models is planned and executed and the 
models now become part of the day-to-day business processes. 

4. Continuous organizational improvements are made. EM could support some of 
these improvements. Changes of greater importance will most likely cause the 
process to start over from step 1 . 

The outcome or effect of the implementation of models is very much dependent 
on the following two aspects: 

• How the EM project is planned and executed (Chap. 9). Managing modeling and 
model quality is one aspect here (Chap. 12) as well as the many facets of 
managing the EM project as a whole. 

• How the implementation and continuous improvement of the resulting models is 
planned and executed over time. 

Effectively managing quality throughout the project will ensure that the intended 
effect of modeling and the resulting models will materialize, not only from a short- 
term perspective but also long-term. In the following we will address two critical 
issues for succeeding: managing triggers (see Fig. 11.1) and establishing mecha- 
nisms for managing continuous organizational improvement using EM. 
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11.1.1 Managing Triggers: Acting on Symptoms or the Real 
Root Cause 

In order to ensure that the process of continuous organizational improvement serves 
the purpose of making the organization fit to take on its challenges and to prosper, it 
is essential to act on the “right” signals/triggers. This implies that the analysis of 
triggers needs to get enough qualified attention, as a basis for making decisions 
about starting a change process. This will ensure that the EM project rests on a firm 
ground already from the start. We want to start the EM project for well-grounded 
reasons and with a goal that will effectively improve business operations. To 
illustrate this point, we describe two real life cases, one successful and one less 
successful. 



11.1.1.1 A Successful Case: Getting at the Root Causes 

A construction vehicle supplier (Company A) with workshops for repair and 
maintenance all over Europe wastes time and money. Some 5-10 administrators 
in each region are involved, on a daily basis, to handle incorrect invoices. This is 
due to invoices stating the wrong amount and/or receiver. After correcting the 
errors, they finally send the correct invoices. Too many people are involved in 
correcting errors, customers as well as administrative staff. This causes irritation 
and dissatisfaction for everyone involved, but most serious problem is that no value 
is created. 

Nobody can state the “one and only” root cause to the problem, so a problem 
analysis, using EM, is carried out to find the root causes to the problem. In order to 
involve the right participants a stakeholder analysis is also made. A group of five 
primary motivated stakeholders are selected to carry out the problem analysis, using 
goal and problem modeling. A modeling facilitator guides the process. 
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In contrast to the visible symptoms the following severe root causes are identi- 
fied in the analysis. They are supported by hundreds of post-its on a big plastic sheet 
on the wall, well sorted/related to each other: 

1. The processes and their interfacing objects are not well defined. One aspect is 
mixed value-chains where, e.g., a vehicle all of a sudden became an invoice in 
the same process. Also, the input/output objects for governing and supporting 
processes are not enough specified, meaning that the repair workshop process is 
not quality controlled. 

2. At the customer reception the rules and policies to conform to are too broad and 
complex and not easily accessible so the receptionists hardly adhere to them. 

3. The way to measure and reward responsible actors is in severe conflict, e.g., the 
workshop and service contract managers’ KPIs are not aligned. Rather they are 
in conflict. 

4. There is a lack of functionality and data accessibility in the IT support and there 
are also a variety of different systems in use. All in all, the IT support does not 
support the processes. 

A number of walk-through sessions are then organized, involving stakeholders 
with the role to criticize the model; in such sessions, important stakeholders who 
have not been involved in creating the models are invited to discuss and criticize the 
models. This increases the quality of the analysis and invokes broad participation 
and commitment to invest and solve the key problems, i.e., it paves the way for the 
coming steps of successfully improving the business operations. The four root 
causes become the basis to set a distinct purpose for the following modeling project. 



11.1.1.2 A Less Successful Case: Acting on Symptoms 

In an international high-tech company (Company B) a number of problems are 
experienced in the existing order process. The problems mainly concern work 
overload, long lead-time, and quality problems. 

No systematic problem analysis is made. The process is initially not described in 
relation to its context, so the interfaces to other processes are not included in the 
first modeling workshops. 

The purpose of the first analysis is unclear, meaning that the needed level of 
detail is not indicated. Substantial time and resources are spent. The project finally 
makes a proper problem analysis and finds the sources of the main problems. They 
are located in processes before and after the order process, which was initially the 
focus of the analysis. 

The modeling project is expanded to include the whole process from sales to 
delivery, thus including the order process. 

The analysis finally results in (1) demands for IT development targeting 
enhancements to the interfaces between existing IT systems and (2) formulation 
of process interface agreements between the main processes. 
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No modeling method is used from the start. Later an EM method is used, both in 
order to identify and define the context of the process and to identify the process 
interfaces. Based on a concepts model, the terminology is aligned between the 
processes, thereby minimizing misunderstandings and as a basis to update the 
requirements on data availability in the IT support. However, by then the company 
has spent a large amount of resources not getting anywhere in their efforts to solve 
the problem. 



11.1.1.3 Lessons Learned 

Already when we are very young we stress our parents by asking the question 
“WHY?” until we think we have a good enough answer. Only then we are pleased. 
This behavior is natural to us as humans and is one of the most important and easy 
to use “tools” in problem analysis. Therefore, the main lessons that we leam from 
the above cases are: 

• The situation that initially triggered the need for change must be clearly identi- 
fied, and as soon as possible too. Otherwise valuable time and resources will be 
wasted. Acting on symptoms is like not asking the question “WHY?” enough 
times to understand the problem at hand. 

• It is essential that the project manager or consultant involved arms herself/ 
himself with sufficient arguments to justify why investments should be made 
in problem analysis before the EM project is initiated and planned. 

• It is advisable to use a proven easy-to-use method, for instance goal/problem 
analysis following the 4EM method. 



11.1.2 Establishing Mechanisms for Continuous 
Organizational Improvement Using EM 



When a future state process is implemented following a 4EM project, a responsible 
process owner is in control. Measurements are in place and used for continuous 
follow-up, subsequent rewarding of good process performance, and identification 
of triggers for continuous improvement of organizational operations. New oppor- 
tunities and threats emanating from external or internal sources will challenge or 
ask for attention and potential new developments, some needing support from EM. 

The complete “map” of existing enterprise models will function as important 
input to future improvement projects. This way unnecessary modeling work can be 
avoided. Even if the organizational context has changed slightly, the existing 
models will provide a good starting point. For more on reuse of models in various 
contexts, see Chap. 13. 
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Since models will be extensively reused, it is essential that their quality is high 
(see Chap. 12). The reuse of models will also require good tool support (Chap. 5) 
that enables change management of models. 

Company A (Section “A successful case: getting at the root causes”) is a positive 
example of an organization where continuous improvement using EM is in “the 
spine” of all employees. What differentiates this organization is that: 

• There is a defined process intended to support continuous improvements, where 
one of the initial phases is conducting Enterprise Modeling using a similar 
approach as 4EM. 

• The enterprise culture and leadership supports continuous improvement. 

• All employees are treated as experts in their role. 

• The personnel is loyal and proud of the company and their own work. 

• A problem is always turned into a possibility. 

• Working in teams is encouraged. 

• “Right from me” is a well-established attitude of all personnel. This means that 
people make sure that what they deliver is correct and follow a high standard of 
quality. 

• There is an established arena for dialogue/control/support, where all improve- 
ment activities are prioritized, are followed up, discussed, supported, and 
visualized. 

• There is an awareness of the fact that change may take time and is done in small 
controlled steps. 

The effect of adopting this approach, where Enterprise Modeling has an impor- 
tant role, is that the process of continuous improvement is kept alive and that 
external and internal triggers for change are properly analyzed and acted upon. 
Company A has proved to have a high degree of satisfied customers. It has also 
proved to have a high resilience in difficult times. For instance, in one of the latest 
financial crises many companies decided to lay off personnel. In Company A, on 
the other hand, the employees showed their loyalty by accepting a 4-day working 
week and a subsequent loss of salary of about 10 %. During the crisis the company 
involved their personnel in training activities. When the crisis decreased everyone 
was ready to start again but with an even better capacity. 



11.2 Overview of the Adoption Process 

In the previous section, an example was given on how Enterprise Modeling can 
become an integral part of an organizations’ continuous improvement work. In this 
section we provide an overview of the process of adopting an EM method as part of 
such an improvement approach. In the following sections, the different steps of the 
adoption process are discussed in turn. 



1 1.2 Overview of the Adoption Process 
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Despite the advancements in the areas of modeling methods and tools, their 
impact in practice is largely dependent on how an EM method is adopted and 
institutionalized. In practice EM usage often follows the phases of initial interest, 
pilot project, and subsequent institutionalization. The most challenging is the final 
one because at this stage the organization should presumably have enough compe- 
tence to perform modeling without external support. In cases when this is not so, 
modeling struggles to make positive impact and is gradually forgotten. Therefore, 
the process of adopting a method should be given the proper attention and 
resources, in order to be reasonably successful. 

The general process of adopting an EM method in an organization consists of the 
following phases: 

• Deciding that an EM method should be adopted as part of the organization’s set 
of institutionalized methods 

• Selecting a suitable method 

• Implementing the method 



11.2.1 Deciding that an EM Method Should be Acquired 
and Adopted 



The decision to adopt an EM method as a part of the organization’s set of 
institutionalized methods often originates from the organization having been 
involved in projects where external consultants have used EM for purposes 
described in Chap. 2. This often generates an interest, particularly if the results 
from such projects have been successful, and a decision to acquire and adopt a 
method may follow. 



11.2.2 Selecting a Suitable Method 

A method for EM consists of modeling language, modeling process, and modeling 
tools. Since the selection of tools is extensively addressed in Chap. 5, the focus here 
will be on the language and the process. 



11.2.2.1 Selecting a Modeling Language 

The core of EM is the modeling language because that determines which aspects of 
a certain problem that can be addressed. 

In most cases a certain problem to be addressed can be modeled by using several 
EM languages/notations. Even within one modeling language the modelers often 
define “dialects” and sub -notations, i.e., they add elements of secondary notation 
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such as comments, groupings of modeling components, as well as include modeling 
components from other languages. 

The choice of modeling language is to a large extent dependent on the purpose 
for which EM will be used. The more specific the purpose, the more specialized the 
language can be. A broad range of intended purposes makes it more difficult to find 
a language that perfectly fits all purposes. However, as was previously pointed out, 
there is often room in a language to make adjustments to fit the situation. 

When an organization decides to adopt EM as a general way of working and not 
only for carrying out a specific project, it may be appropriate to select more than 
one language to cater for intended purposes. For example, using EM for developing 
visions and strategies and as a general problem-solving tool can require a different 
level of formality compared to using EM for developing information systems. As a 
general rule, languages originally intended for developing information systems, 
e.g., UML, are often more difficult for non-modeling-experts to understand and 
work with, which suggests that they may not be the optimal choice for problems 
less formal. 

In cases where more than one language is selected, the issue of integration 
between the languages comes into play. For example, process models are part of 
both 4EM and UML. In projects dealing with information systems development, 
decisions need to be made which models will be used in the more business oriented 
part of a project, where understandability is essential, and how these will be used in 
the more systems oriented part. Adopting more than one modeling language also 
influences the choice of tools (Chap. 5), more specifically computer-based tools. 
One issue here is how models created in one tool can be integrated with models 
created in another tool. 



11.2.2.2 Selecting a Modeling Process 

A general process for carrying out an EM project is described in Chap. 9, reflecting 
a participatory approach to modeling. Although this is the recommended way of 
working, a less participatory approach can be appropriate under specific circum- 
stances, e.g., if the organizational culture does not allow for different views and 
opinions being expressed in a group setting. Some steps in that process can then be 
omitted and some may be added. This means that an organization may adopt more 
than one general modeling process. In any case they should be documented and 
made easily available to the organization in order to support the modeling experts 
and business stakeholders in their work and to standardize the process between 
specific projects. Such standardization will save time for modeling experts. It will 
also familiarize business stakeholders with the modeling process and by that make 
them feel more secure in their participation throughout the various projects that 
they will be involved in. The introduction of newly employed modeling experts into 
the way of working of the organization will also be smoother if the process is 
documented and easily available. 
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11.2.3 Implementing the Method 



As indicated, implementing a method in an organization is the most difficult and 
time-consuming part of the adoption process. There are many issues that need to be 
addressed in the process, e.g., how to acquire a method, whether or not to adapt the 
chosen method, acquiring competent modeling experts, acquire modeling tools, and 
starting to use EM. Also, evaluation and making adjustments to the implementation 
should not be neglected. The acquisition of EM tools is discussed in Chap. 5 and 
will, therefore, not be further discussed here. 



11.2.3.1 Acquiring a Method 

An EM method consists of a modeling language and a modeling process. Some 
methods, like 4EM, come with a predefined modeling process (Chap. 9) but most 
methods do not. Therefore, the process of acquiring a method should also include 
selecting one or more ways of working, both in terms of the overall process of 
carrying out an EM project and in terms of ways of working within a project. For 
example, will participatory modeling sessions be used or not. The chosen ways of 
working will most certainly influence which competence will be needed. More 
regarding modeling competence can be found in Chap. 10. 

EM languages can be commercially available or they can be research based. 
When acquiring a modeling language it is important to consider its long-term 
sustainability, in addition to the fitness for purpose as discussed in Sect. “Pilot 
Projects.” Commercially available languages come at a price but on the other hand 
they may be more widely accepted and their long-term development is taken care of 
by the supplier. The ownership of the method is in such cases clear. Research-based 
languages may very well be suited for their intended purpose(s) but the organization 
needs to ensure that they have been tested properly and that the method documen- 
tation is freely available. 



11.2.3.2 Adapting the Method 

Sometimes adaptation to the method needs to be made, particularly if the chosen 
EM method is intended to integrate with other methods, e.g., systems development 
methods. However, it is advisable only to make the really necessary adaptations in 
the beginning. After a few pilot projects (see Sect. “Pilot Projects”) an evaluation 
can be carried out and further adaptations can then be introduced, if necessary. 
However, too many local adaptations to a method will make the method more 
difficult to maintain over time. It will also cause problems and additional costs in 
terms of adaptation of computer-based tools. 



198 



1 1 Adoption of Enterprise Modeling 



11.2.3.3 Acquiring In-house Modeling Competence 

Most probably the organization will not have competent EM experts among its 
employees. This means that they will have to be hired. The different levels of EM 
competence (see Chap. 10) should be considered here, i.e., ability to model, ability 
to facilitate modeling session, and ability to lead modeling projects. 

It should be noted here, that in order for an organization to be able to handle 
modeling projects on their own, the last two abilities are critical. Unfortunately it 
may be difficult to hire people who already have these abilities, because they take a 
long time to acquire. Hiring people on the highest level of competence may even be 
impossible. In those cases the organization may start out with a few simple projects 
with less experienced modeling experts that are hired from outside. 

An alternative to hiring modeling experts is to train employees who have shown 
an interest in EM and let them start working with some simple modeling projects, 
preferably under the supervision and mentorship of external experienced consul- 
tants. These projects should be evaluated from a competence perspective. Addi- 
tional training activities can then be initiated based on the evaluation. 

Since modeling expertise takes a long time to build it is essential to allocate 
resources for competence assessment and development during a number of years. 
Also, planning for continuous exchange of experiences and mentoring between 
modeling experts will decrease the vulnerability of competence since it can help 
easing the dependence on individual modeling experts and allow individuals to 
develop from one competence level to the next. 



11.2.3.4 Pilot Projects 

When an organization starts to carry out its own modeling projects, some pilot 
projects should be initiated that are designed to test the modeling language, the 
modeling process, the modeling tools, as well as the modeling competence. Eval- 
uation criteria should be carefully defined. The series of pilot projects should be 
selected to reflect the different purposes for which the organization intends to 
use EM. 

Most probably the organization will need to hire consultants to supervise the 
pilot projects and also to set up and carry out the evaluation. 



11.2.3.5 Evaluation and Adjustment of the Method 

In order to ensure that the chosen method will be useful over time, the organization 
also needs to document it and to organize its maintenance. 
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The maintenance of the method entails not only updating the documentation 
when the method evolves over time (and it probably will) but also setting up an 
evaluation process targeting modeling projects that are carried out in the organiza- 
tion. Criteria for selecting the modeling language and modeling process should be 
used in the evaluation, together with evaluation of the outcome of modeling 
projects. 

Based on the result of the evaluation, different adjustments to the method may be 
needed. However, care should be taken so that these are not made hastily and 
frequently because it will cause unnecessary uncertainty and instability in the 
organization. It is advisable that any adjustments are based on at least 2-3 projects 
and that they are documented properly and also communicated to the organization. 
The communication aspect is particularly important, since people tend to stick to 
old habits. 

The evaluation can also show that the competence of method experts needs to be 
enhanced. Different training activities and exchange of experiences between 
method experts should then be initiated. 



11.3 A Short Note on Training of Modeling Experts 

It is clear that participatory EM is a complex process that requires knowledge and 
skills. This is something that takes time and a lot of extensive practice to acquire. 
The following quote from an interview with an experienced modeling expert 
illustrates the problem: 

“We interviewed 73 or 74 potential facilitators. Out of these we chose 15 who we thought 
were at least reasonably good. Towards the end we had seven left. This is the real situation. 

We lost some on the first level. They didn’t really have the ability to model. Some we lost on 
the second step. They didn’t have the ability to facilitate modelling sessions. Then we lost 
some because . . . well, all facilitators are exhibitionist prima donnas . . . but some had too 
many co-operation problems 

The question is then, how modeling experts can become skilled. It is self-evident 
that training to become a skilled participatory EM method expert involves acquiring 
knowledge that is provided in the literature or by taking courses. However, most of 
the training must be focused on practice, in order to become more and more skilled. 

It can be difficult to organize “learning by doing,” with feedback loops in a 
systematic and practical way, for a large group of people. A complicating factor 
here is that the person being trained needs to be subjected to a variety of situations, 
in order to be prepared for future assignments. Also, since the situation in real 
projects is often sensitive, there is no room for critical mistakes. This means that the 
number of skilled participatory method experts increases very slowly. 

A practical way is to work together with more experienced facilitators. Novices 
should never facilitate alone, since the errors made during modeling will negatively 
influence the outcome of the process where modeling is used. With reference to the 
maturity levels of method experts, a common mistake that novices make is that they 
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believe that just because they have learned to master a modeling language, they will 
be able to carry out a participatory modeling process. 



11.4 Organizational Structure Supporting EM: The 
Modeling Department 



In the previous sections of this chapter, we have discussed the activities that lead to 
adopting an EM approach in an organization. The result of these activities should be 
a pool of competent employees that can be used in EM projects, which in many 
cases may require creating a supporting organizational unit dedicated to modeling — 
a modeling department. The following roles should be considered for inclusion in a 
modeling department: 

• Facilitator — as discussed in Chap. 10, the modeling facilitator leads and advises 
the modeling participants during modeling sessions. 

• Method expert — organizations that have been more successful in using EM all 
had one or several persons who were very knowledgeable about the modeling 
method (or several methods) used in their organization. They were also very 
enthusiastic about the modeling way of working. Their enthusiasm also moti- 
vated their colleagues’ support and engagement in modeling. We call them 
“method experts” while actually “method champions” would be more correct. 
Often these people have been the first in their organizations who tried to “sell-in” 
the modeling way of working to their organization. Another responsibility of 
method experts is to be responsible for the development and maintenance of the 
modeling method used and if necessary integration with other methods and 
approaches used. 

• Tool expert — in order to use an EM method efficiently, a modeling tool is 
needed and, hence, the organization should also have in-house competence 
concerning the modeling tool(s) used. For example, the different integration 
possibilities with other tools and configurable information systems, presentation 
possibilities on the web, collaboration support, tool versions and upgrades, etc. 
are in the competence area of the tool expert. Depending on the actual methods 
and tools used and background of the people involved, the method and tool 
expertise can be combined and fulfilled by the same person(s). 

• Model maintenance and presentation expert — modeling maintainers are required 
if the company wants to keep their business models up to date. In larger 
organizations where many different EM activities take place at the same time, 
modeling facilitators may not have the time to fine-tune the models, for instance, 
to the levels of presentation quality required for publishing the models on the 
intranet. Hence, the modeling department may include staff experienced in 
documenting models for various purposes — e.g., for presentation, for inclusion 
in reports, requirements specifications, etc. 
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Building of a modeling department depends on the organization’s intentions 
regarding the long-term use of Enterprise Modeling. If the organization wants to 
model without external consultants or keep models “alive,” then it has to develop its 
own in-house EM competency. Such a task cannot be accomplished “over night” — 
time is needed for the personnel to learn the EM method, to develop modeling 
skills, to develop in-house modeling guidelines and procedures, as well as to 
accumulate experience. An organization planning to do this should also be aware 
that developing and sustaining a modeling department requires considerable 
resources. 




Chapter 12 

Quality of Enterprise Models 



EM usually leads to organizational change and/or development. In some cases this 
change can be implemented without initiating bigger change projects or the intro- 
duction of IT support. In these cases the different models developed might be used 
only for documentation purposes. In the majority of the EM projects, the models 
created will be continuously refined, improved, and transformed and, hence, they 
need to be of high quality. 

This chapter discusses the notion of model quality and introduces selected 
techniques for model refinement. 



12.1 Fitness for Purpose: A Basic Quality Criterion 



The quality of enterprise models produced in different projects differs depending on 
the project objectives and the purpose of models. According to Persson (1997a, b) 
the main criteria for successful application of EM are that: 

1 . The quality of the produced models is high, 

2. The result is useful and actually used after the modeling activity is completed 

3. The involved stakeholders are satisfied with the process and the result. 

Larsson and Segerberg (2004) have investigated whether the quality criteria for 
data models defined by Moody and Shanks (2003) are applicable to enterprise 
models and proposed several modifications to the original criteria. The resulting 
quality criteria for EM are: 

• Completeness — the degree to which all relevant facts of the problem domain are 
included in the enterprise model. 

• Correctness — refers to how well the enterprise model conforms to the rules of 
the modeling technique. 
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• Flexibility — is defined as the ease with which the enterprise model can cope with 
changes in the modeling domain. 

• Integration — refers to the degree of consistency between the different 
sub-models that constitute the enterprise model. 

• Simplicity — refers to the degree of minimal use of modeling constructs for 
presenting knowledge in the enterprise model. 

• Under standability — is defined as the ease with which the concepts and structures 
in the enterprise model can be understood by the stakeholders. 

• Usability — is defined as the ease with which the enterprise model can be used for 
its intended purpose. 

What quality criteria are relevant and how strictly they are to be followed 
depends on the purpose of modeling or goals of modeling according to (Krogstie 
et al. 2006; Krogstie 2012). The remainder of this section discusses a number of 
generic purposes of modeling with respect to what quality criteria they require. 

If the purpose is to develop vision and strategies, the main quality requirements 
are understandability, correctness, simplicity, and flexibility, which are the key 
factors supporting efficient communication among stakeholders. 

If the purpose is to design/redesign the business and or information system, the 
enterprise model presents an organizational and IS design and hence models should 
comply with quality requirements in terms of completeness, correctness, flexibility, 
integration, and usability. Referring to the choice of the modeling language in this 
case, the understandability for a broad range of stakeholders might be reduced by 
the need to use a language that allows reaching a higher degree of completeness, 
correctness, and integration. 

If the purpose is to create, maintain, and share knowledge about the business, the 
main quality requirements are correctness, integration, understandability, and 
usability. Special emphasis should be put on ensuring that the models are under- 
standable for the target audience without extensive training in a particular modeling 
approach and language. 

In some projects EM is used only as a problem-solving tool and the models are 
only used as documentation of the discussion. In such cases the main quality 
requirements are correctness, flexibility, and understandability. 



12.2 Basic Principles of Modeling 

There are a number of basic principles of modeling addressing syntactic, semantic, 
as well as pragmatic demands on the proper creation of process models proposed in 
(Becker et al. 1995). They are also applicable to enterprise models. There principles 
are: 

• The principle of accuracy — the model complies with the corresponding excerpt 
of the real world. 
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• The principle of relevance — modeling constructs should be included in the 
model with a purpose, not all reality should be represented in the model. 
Which information is relevant for a model depends on the intended use of the 
model. 

• The principle of economical efficiency — the costs of modeling should not exceed 
the intended benefit, i.e. Enterprise Modeling should not be used for addressing 
trivial problems that can be resolved otherwise. 

• The principle of clarity — models should be presented legibly and clearly, with- 
out more constructs than necessary 

• The principle of comparison — models created with different modeling tech- 
niques should be comparable at least to some extent. 

• The principle of Systematic Structure — if several models are created they should 
be connected in some structure in order to show how they contribute to the 
overall purpose of modeling. 



12.3 Improving Enterprise Model Quality 

This section presents several practical tips how to improve model quality. Much of 
this is related to using the modeling method and the language as intended; hence 
many more suggestions for each 4EM sub-model can be found in Chap. 8. The main 
focus of this section is on recommendations applicable to the enterprise model as 
whole. 



12.3.1 Unambiguity 

Ambiguous models are difficult to understand and to use. Hence we should strive 
towards unambiguity. Ambiguity is mostly induced by formulations of the model- 
ing components. In Chap. 8 we have given several suggestions, e.g., starting goal 
formulation with “The goal is. . .”. Another aspect of ambiguity is lack of concrete 
detail and decisions that can be taken up and implemented. E.g. it sometimes 
happens in modeling seminars that the stakeholders discuss the problem and the 
solutions on a too high level of abstraction and omit specific details. As a result, the 
model is too vague or too “kind” and deals with the problem at hand on a superficial 
level without proposing concrete description of what needs to be done. In this case 
one solution is to identify concrete actions that need to be carried out and who will 
be responsible for them. They can be modeled as business processes and individ- 
uals, respectively. Such questions normally make the discussion more realistic and 
lead to concrete decisions concerning who is doing what, why, and how. Without 
this, the risk is that the modeling seminar ends up with a model resembling 
something coming from a textbook — correct but lacking company specific details 
and hence not useful for further development activities. 
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12.3.2 Model Flexibility and Stability 



An enterprise model should be built in such a way that minor changes in the domain 
area do not force major changes in the model. In other words, it should be possible 
to add or remove some elements from the model without major changes or 
restructuring the rest of the model. In many cases the way the model will evolve 
is hard to predict and the modeling participants should not worry about this — after 
all modeling on the plastic wall allows for changes, reasonably easily. Flexibility 
becomes a more significant concern in later stages of modeling and when the 
modelers are starting to think about the subsequent development stages. Even at 
these stages, changes still occur but making them is more cumbersome. For 
example, the goal structure in Fig. 12.1 — goal 3 is supported by three other goals 
addressing the manufacturing process. We can also consider that there are other 
ways of cutting costs, e.g., by reducing the number or business travels. This leads us 
to conclude that these three goals are about a certain solution area for goal 3 — the 
manufacturing process in which case we can define a new subgoal 4 (Fig. 12.2). 
There could be more ways to optimize the manufacturing process than the three 
subgoals 4.1, 4.2, and 4.3, consequently we can assume that the GM fragment in 
Fig. 12.2 is more stable than in Fig. 12.1. 



12.3.3 Homogeneity 

A modeling component is said to have a high degree of homogeneity if the real life 
occurrences it represents are very similar to one another and display the same kinds 
of properties and relationships. In principle homogeneity can be seen as similar to 
cohesion — the degree to which an element contributes to a single purpose, com- 
monly used in Object Oriented (00) design. That is in 00 design we should strive 
towards high cohesion because classes with low cohesion have many unrelated 
responsibilities and are difficult to understand, maintain, reuse. They also need to be 
changed very often. More on the principle of high cohesion is available in (Larman 
2004). Cohesion as a principle can also be applied in EM, especially for assessing 
concepts models, but we believe that homogeneity is a more suitable principle 
because of the different perspectives that enterprise models represent. Homogeneity 
normally is not a target on its own — instead it contributes to factors such as 
flexibility, simplicity, understandability, and, in turn, usability. 

For example, Fig. 12.3 shows a goal formulation that potentially contains several 
goal statements. Modeling components that are formulated in this way often are 
elicited in modeling sessions because stakeholders are not aware of this principle 
and may write fairly long statements. It is the responsibility of the modeling 
facilitator to notice such issues and refine the modeling component. In this case 
the initial formulation is decomposed into two subgoals (Fig. 12.4). 

In concepts modeling homogeneity is usually improved by introducing general- 
ization/specialization hierarchy. Consider concept 6 “Product” in Fig. 12.5 has two 
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Fig. 12.1 Unstable goal model 




Fig. 12.2 More stable GM fragment, achieved by introduction of Goal 4 refined by AND/OR 
decomposition structure of subgoals 

sub-concepts “product with engraving” and “standard product.” Without this spe- 
cialization concept “product” would have to represent both kinds of products — with 
engraving and standard. This would mean that a number of other modeling com- 
ponents such as rule 6 and process 13 would have to be connected to it, but they 
would only apply to some products. In this case the “product” would be 
nonhomogeneous. The specialization shown in Fig. 12.5 increases the overall 
homogeneity by having a clear purpose for each concept: 
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Goal 1 

Increase profits of the enterprise by 
15% during the next fiscal year by 
promotional measures and reduction of 
operation costs 



Fig. 12.3 Nonhomogeneous formulation of a goal 




Fig. 12.4 Overall homogeneity of goals is improved 




■ relates to—* 



i 

Process 13 (+) 



Create a 
standardized product 



Fig. 12.5 A fragment of CM showing specialization of a concept and inter-model links 



• Concept 6 “Product” is used for representing the common properties for all 
products, such as having purchased. 

• Concept 7 “Standard product” represents all standard products. 

• Concept 8 “Product with engraving” represents all custom made products with 
engraving. 
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12.3.4 Completeness and Scope 

All relevant knowledge of the problem domain should be represented in the model. 
Models should not include aspects that are not relevant to the problem domain. 
While these are straightforward principles of modeling, there are several issues we 
would like to point out. 

An enterprise model always has a scope that is determined in the preparatory 
stages of the modeling project. The scope serves as delimitation to what is impor- 
tant for modeling and what is not. There sometimes is a misconception that EM 
somehow leads to (or even requires) modeling the entire enterprise. In reality, this is 
seldom the case. Each EM activity usually has a fairly specific and sometimes quite 
narrow scope, which helps the modeling activity to achieve results of value to the 
stakeholders and to the company. Determining the scope may, however, be tricky 
because of the following issues: 

• The customer or the problem owner might not know or recognize what the real 
problem might be (blurred scope). 

• There could be disagreement among stakeholders about what the scope really is 
(multiple scopes) and the modeling activity first needs to establish a consolidated 
scope. 

• The real scope might be covered, in which case the modeling team has to deal 
with hidden agendas. 

• The scope may often change during modeling because the participants learn new 
knowledge about the problem and want to extend, narrow, or shift the scope. 

In cases of blurred scope or multiple scopes, we recommend arranging a short 
modeling session focused on setting the scope for the EM project. This might also 
be useful when dealing with hidden agendas. For example, Fig. 12.6 shows a group 
of stakeholders modeling business problems of their company. This was part of the 
first modeling session of the project and the purpose of this session was to analyze 
the current problems (there were quite a few) and to set the scope for the project. 

Completeness reflects to which degree all relevant facts of the problem domain 
are included in the model. In practice the challenge is twofold: (1) the problem 
domain (scope) might not be clear (this we have discussed above); (2) there might 
not be enough time and/or stakeholder interest to elaborate the model to the level of 
completeness required for the next development activity. That is, stakeholder time 
is valuable and hence it might be difficult or too costly to engage them in modeling 
relatively simple or well-known aspects of the solution. Even if these aspects are 
needed for implementation, e.g., modeling attributes in the CM or certain corporate 
procedures in the BPM, the stakeholders may perceive such a task to be too trivial 
participatory modeling. In such cases the participatory approach should be 
substituted by other modeling techniques (e.g. modeling based on interview results 
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Fig. 12.6 The modeler in discussion with the stakeholders of the company (enterprise model is 
visible in the background as initial version on plastics and as electronic version) 



or consultants modeling these aspects in a consultant-driven mode) and presenting 
the resulting model to stakeholders in a walk-through modeling seminar. 

In summary, the desired level of completeness depends on the project objectives 
and should be determined in the project initiation stages. 



12.3.5 Integration 

Enterprise models address the problem being modeled from different perspectives. 
This multi-perspective view on the problem domain is one of the key strengths of 
EM. Hence, integration is a factor that significantly contributes to understandability 
and usability of the model. Each sub-model should be connected internally and with 
other sub-models. Some guidance for integration can be derived from the meta- 
model of 4EM, for instance: 

• There must exist at least one goal in the GM, one process, one external process, 
one information/material set in BPM, one concept in CM, and one actor in ARM. 
This is based on the basic principle that an organizational design should be 
functional and without at least rudimental designs in each of these areas this 
would not be the case. 
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Fig. 12.7 A simple line of reasoning from goals to processes and to requirements 

• Every Information or Material Set in the BPM must be related to a concept in the 
CM. The motivation for this rule is that information and material are part of the 
conceptual structure of the company. 

• Every process must be motivated by at least one goal from GM in some 
decomposition level. The rationale for this rule is that processes should deliver 
business value defined by goals, and that there should not be processes that the 
company does not need. 

• Every process must be related to at least one ARM role, which is responsible for 
or performs that process. 

• Every information system goal and requirement must be related to at least one 
goal or business process. These relationships aim to establish the alignment 
between the business design and the information system. 

Models should complement each other, i.e., what we discuss in one sub-model 
should also be addressed in other models. For example if the Goal Model heavily 
deals with concepts such as sales, different types of products, and customers then 
these would have to be defined in the Concepts Model, and there would have to be 
business processes managing these concepts, etc. The inter-model links should 
establish a clear line of reasoning. In simple cases it might be rather obvious, see 
Fig. 12.7, showing one-to-one correspondence between a goal and a process and a 
requirement. Such cases are rather easy to discuss and it is also easy to develop 
corresponding inter-model links here. 

This is however not always as explicit as discussed above. In other cases there 
might be business goals that address crosscutting concerns relevant to a specific 
solution and hence they may motivate several processes or a certain way a process 
is designed. For example, Fig. 12.8 shows a goal “to facilitate knowledge sharing 
during project delivery.” Such a goal cannot realistically be implemented by a 
process named “facilitate knowledge sharing.” Instead, the process of project 
delivery needs to be designed in such a way that it facilitates knowledge sharing. 
Sub-processes that incorporate knowledge sharing activities should then be linked 
to the goal in order to show the support. 



12.3.6 Simplicity and Complexity 

Simple models are more understandable. They are also easier to improve, maintain, 
and reuse. The guiding principle recommends using as few modeling constructs as 
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possible. While this principle seems to be almost universally applicable, in practice 
many models are complex or at least appear to be complex. They contain a large 
number of components, relationships, and decomposition schemas. This is probably 
so because modeling, and especially Enterprise Modeling, is called upon in situa- 
tions when the problem and their solutions are not trivial. The invariance of 
modeling is that complex problem domains probably lead to complex models at 
least on some refinement level, as the following situations shows. 

Example case: We were modeling business processes for certifying public transport 
operators at a municipality. The stakeholders had no prior experience with business 
process modeling. After two modeling workshops they started to raise concerns about the 
way of working — the model representation of the procedures at this department seemed 
very complex to the stakeholders. And, indeed, they were — the model was six A4 pages long 
and two pages wide, containing several iterations and many information sets. “ Why are you 
( method providers ) doing this in such a complex way?” — one of the stakeholders asked. She 
was somewhat surprised when we replied — “ but this is the way your department actually 
works” . We then explained the model step by step. Only after this the stakeholders realized 
the actual complexity at their workplace and started to look for alternatives of making this 
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business process simpler and more efficient. The resulting model contained considerably 
fewer activities and information sets and the stakeholders found that two actors did not 
need to be involved in the process at all. 

What we can learn from this case is that complexity as such is not harmful and 
can lead to improvements of the overall design. But unnecessary complexity needs 
to be dealt with because it hampers under standability. 

Complexity is in practice influenced by a number of factors — visually perceiv- 
able and project related. Project related factors are the following: 

• The complexity of the problem domain. Some domains have more stringent 
requirements for formality and level of detail for solutions to be specified, which 
requires a more complex model. See example quote below. 

• The novelty and difficulty of the project objectives. There seems to be some 
evidence suggesting that without experience from a particular application 
domain, people tend to develop more complex models. This might also be 
related to the fact that they are unaware of what is truly important and at what 
level of detail the models should be developed. 

• The purpose of the models. The models that are intended for information system 
development or configuring an ERP system will need to be more rich in detail 
(and, hence, more complex) than models that are used for sharing knowledge 
about the way of working within the company or for capturing a brainstorming 
session. 

“The complexity of the project is difficult to foresee in advance. If you have done similar 
projects in the past in the same department, then you already know what to expect. You know 
how they work and what are their main problems. But if you have a completely new problem 
in a place you have never been, then it is very difficult to estimate the complexity beforehand. 
Even if the objective and your task look simple in the beginning, you never know what might 
surface once you start working. .. .the complexity can increase very rapidly. 

Then, of course, we have projects of modelling [a certain telecommunications equip- 
ment] and procedures associated with them . Those are very complex because the equipment 
is very complex and it needs to be modelled in great detail.” ( Interviewee 8, p.306, in Stima 
2001 ) 

Among factors influencing complexity visually, is the number of modeling 
components, relations, sub-models, schemas and model fragments, as well as 
structure and symmetry of the model. According to our experience it is the 
latter — model structure and visual appeal that often influence the perceived com- 
plexity and, consequently, understandability of a model. For example, Fig. 12.9 
(below) shows three models with various degrees of structure. Model A visually 
appears the most complex because it lacks an overall structure. Model B has an 
overall structure of sequence and model C has an overall tree structure which 
probably makes these seem less complex than A. 

An additional factor influencing perceived complexity and consequently reduc- 
ing understandability is disregarding common layout principles. For example 
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Fig. 12.9 Various degrees of structure 



process models are normally built from top to bottom or from left to right; in 
concepts models the more significant concepts are placed in the middle of the 
diagram. In goal models more strategic goals are usually placed on the top and 
operational goals below. The “supports” relationships usually point upwards or 
horizontally. Figures 12.10 and 12.11 show the same model fragment in two 
layouts — one does not follow this principle; the other does. 

If these common principles are abandoned, the models are difficult to read and 
analyze. In projects involving inexperienced modeling participants, these principles 
might also need to be explained, e.g., that placing more strategic goals on the top of 
the model has certain semantic meaning even if the relationships are not yet defined. 

Experience of the modelers and the modeling facilitator are perceived to have 
some influence on complexity according to findings reported in Moody and Shanks 
(2003). This might be related to the lack of skill in fact gathering or facilitation. 
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Fig. 12.10 A GM fragment that does not follow common layout principles 




Fig. 12.11 A GM fragment following the principle of placing more strategic goals above 
operational goals 
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As a result, the models are less complete. There can also be a lack of skill in making 
models graphically appealing. Our experience shows that it is mostly the skill of the 
modeling facilitator that allows avoiding unnecessary complexity or impractical 
simplicity. 




Chapter 13 

Reuse of Enterprise Models 



Enterprise Modeling projects create a great deal of models. They have various 
purposes, which have been previously discussed. Some are created only to capture a 
particular idea or document the discussion of the stakeholders. But the majority of 
models are created in a design situation and once completed they reflect good 
solutions and best practices for dealing with a specific business problem or corpo- 
rate intention. As a result they have a value that extends beyond the boundaries of 
the project that created them. This value needs to be captured, i.e. packaged in a 
form that facilitates sharing, and then used when appropriate. Individual projects 
considering only their own goals may not have the need to reuse models or to design 
reusable models, but the company as a whole has to work efficiently and capitalize 
on past success by reusing models. 

For example, Fig. 13.1 shows a Concepts Model of a human resource manage- 
ment system of a large utility. This model contains several best practices and 
solutions that can be applied in other contexts and organizations for similar 
purposes. There are more, but in order to exemplify, we have shown two parts of 
the model addressing the following questions: 

- What are the indicators for assessing an organizational unit? 

- What are the indicators for assessing an employee? 

This model was created in a change management project and later implemented 
in the company. What makes it interesting for the purposes of this chapter is that it 
contains best practices, represented by model fragments, which can also be applied 
elsewhere. In this case we have highlighted the indicators for measuring organiza- 
tional units and employees that can be reused in other contexts and organizations. 
However, this cannot be done by simply taking this model and applying it else- 
where, because only parts of it would be applicable, i.e., the knowledge in this 
model needs to be captured and stored. During the task of capturing and storing the 
knowledge, we deal with the following challenges: 
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• How to remove specific material, which is either out of date, too specific to the 
project that created it or confidential? 

Models first serve their primary purpose; the purpose to reuse often comes 
afterwards, for instance when the model proves to be useful. As a result, some 
work is required to make the model reusable by making it independent from 
other parts of the enterprise model, and by generalizing it to a reasonable level 
of abstraction. 

• How to ensure that the stakeholders in the new setting consider applying the 
reused model? 

This is not so much about the NIH syndrome (Not Invented Here), as about the 
need for them to learn another model, the context in which it was created, and 
often also somebody else’s way of thinking. Reuse may also appear somewhat 
contradictory to the overall approach of the participatory way of working that 
ensures stakeholder creativity and commitment. Hence, there is a need to 
incorporate the reuse-based way of working in the modeling and design/devel- 
opment process of the organization. 

In summary, to address these challenges the company needs an approach to 

knowledge reuse focusing on two core issues: 

How to deal with reusable models, i.e., how to capture them, package them, and 
store them in a repository? 

How to incorporate model reuse in the modeling and design! development process? 




Fig. 13.1 A concepts model showing potentially reusable parts 
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There are several useful and not mutually exclusive principles to knowledge 
reuse, such as: 

• Best practices — a concept used in knowledge management in order to capture 
and share good solutions and lessons learned which are of value to the organi- 
zation (c.f., for instance, O’Dell et al. 1998). 

• Frameworks — a concept used in software development for providing building 
blocks for implementing generic functionality of a software system. A frame- 
work usually contains working code that needs to be changed and/or extended in 
order to fit specific application requirements. Examples of software frameworks 
are code libraries, tool sets, and application programming interfaces. The frame- 
work principle is also used in organizational setting as Enterprise Architecture 
Frameworks. These frameworks usually offer generic guidance for creating and 
managing enterprise architecture as well as for the form in which an enterprise 
architecture should be described. Examples of EA frameworks are the Zachman 
Framework (Zachman 1987) and TOGAF (The Open Group 2011). 

• Reference models — are a system of models used to define concepts in a certain 
domain. The aim of reference models typically is to unify and integrate 
the body of knowledge in a certain area. Reference models are not directly 
seen as standards but they often have a significant role in developing them. 
Reference models are frequently used for managing an established set of best 
practices and commonly available solutions. A notable example of using 
reference models for business process management is provided in (Scheer 
and Niittgens 2000). 

• Patterns — a concept for capturing and presenting proven reusable solutions to 
recurring problems initially used in architecture and later adopted to information 
systems analysis, design, programming, as well as organizational design. 

The common principles of these approaches are (1) modularization of a knowl- 
edge chunk (reusable knowledge artifact of value) and (2) providing structure for 
managing and using the knowledge artifacts. In this chapter we take a closer look at 
patterns, because this principle has proven to be useful in various EM related 
contexts before (see, for instance, Rolland et al. 2000; Persson et al. 2008). 



13.1 The Pattern Concept 

In the process of capturing, packaging, storing, and sharing knowledge, we are 
frequently faced with questions such as: how should this piece of best practice or 
experience be represented, is it of any value, what can it be used for, when can it be 
used and by whom. These questions address the two main aspects of a knowledge 
artifact — what is the problem it addresses and what is the solution it provides. 
Alexander (1977) defined such problem-solution pairs as patterns — “a problem 
which occurs over and over again in our environment and then describes the core of 




220 



13 Reuse of Enterprise Models 



the solution to that problem, in such a way that you can use this solution a million 
times over, without ever doing it the same way twice.” Following this definition, 
pattern-based approaches have established themselves in software programming, 
software design, data modeling, and in systems analysis (see, e.g., Coplien and 
Schmidt 1995; Gamma et al. 1995; Fowler 1997) with the common objective to 
capture, store, and communicate reusable artifacts, such as fragments of code or 
diagrams. For example, in object-oriented systems we are sometimes faced with the 
need to restrict the instantiation of a class to only one object. The solution to this 
design problem is known as a Singleton pattern being part of the so-called Gang of 
Four (GoF) Patterns, documented in (Gamma et al. 1995). There are numerous 
pattern collections available in books, incorporated in corporate reuse libraries, and 
on the Internet. A reasonable starting point for investigating the world of patterns 
for information system development is The Patterns Home Page (http://hillside.net/ 
patterns) maintained by The Hillside Group. 

The pattern concept has been further extended and applied in organizational 
development and knowledge management under the term organizational patterns 
(Rolland et al. 2000; Prekas et al. 1999). By organizational patterns we mean 
“generic and abstract organizational design proposals that can be easily adapted 
and reused in different organizational situations.” According to this principle 
patterns have been successfully applied in a number of projects for knowledge 
sharing purposes. 



13.2 The Pattern Template 

There is no general agreement among pattern developers about what patterns 
should look like and how pattern templates should be structured. In practice we 
can see simple templates with a few fields, fairly elaborated templates consisting of 
many fields as well as no templates at all in which case patterns are represented in 
free flowing text. Many patterns, especially in the information systems (IS) devel- 
opment domain, extend textual descriptions with graphical models, e.g., UML 
Class Diagrams, Event Driven Process Chains, and workflow models connected 
to executable IS components. For knowledge management purposes patterns may 
also include multimedia content, which in some cases is helpful to capture more 
tacit knowledge than plain text is capable of doing. 

The EKP approach (Bubenko et al. 2001) used in the ELEKTRA project and in 
the Riga City Council initially suggested a very extensive template with a large 
number of fields aiming to cover many aspects of the knowledge artifact (see 
Table 13.1). This template comprises almost all possible fields imaginable for 
describing patterns. It was found too complex, but it is included here to depict the 
full range of potential aspects to include in a pattern. In later application cases the 
template was tailored according to the wishes of the user organizations and most 
commonly only the following fields were used — name, problem, context, and 
solution. 
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Table 13.1 The pattern template proposed by the EKP approach 



Name of field 


Description 


Name 


Each pattern should have a name that reflects the problem/solution that it 
addresses. Names of patterns are also used for indexing purposes 


Problem 


Describes the issues that the pattern wishes to address within the given 
context and forces 


Context 


Describes the preconditions under which the problem and the proposed 
solution seem to occur 


Forces 


Describe the relevant forces and constraints and how they interact or conflict 
with one another and with goals we wish to achieve by implementing the 
solution 


Solution 


Describes how to solve the problem and to achieve the desired result. Solution 
describes the work needed. It can be expressed in natural language, EKD 
models, drawings, multimedia sequences, etc. Solution can be backed up with 
references to other knowledge sources and other patterns 


Rationale 


Explains why the solution presented in pattern is appropriate in relation to the 
forces, context, and problem 


Consequences 


Describes what the context should be after applying the presented solution, in 
terms of positive and/or negative effects 


Related 

information 


Relationships to other organizational patterns, related documents, Web 
resources, or information systems. These knowledge resources can be located 
either within the organization or outside 


Known 

applications 


Describe where the pattern has been applied 


Authors 


Creators of pattern and their contact information 


Also known as 


Presents aliases of pattern 


Examples 


References to specific application cases of the solution presented in the 
pattern. This field can include references to specific models, organizational 
designs, as well as success stories and lessons learned 


Usage 

guidelines 


Presents a set of usage tips to the potential user of the pattern about how the 
pattern can be tailored to fit into particular situations or to meet specific needs 
of an organization. Guidelines aim to give an idea of how the pattern can be 
tailored to create a specific business solution 


Type 


Describes the type of the pattern (e.g., goal, business process, concept, etc.). 
This field is used for structuring the knowledge repository and for searching 
purposes 


Domain 


Describes the business or activity domain for which the pattern is applicable 
to. Examples of domains are customer servicing, performance indicators, 
restructuring, organizational policies, etc. 


Keywords 


A few keywords are defined for each pattern in order to facilitate search and 
retrieval 
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13.3 The Structure of Patterns and the Concept of Pattern 
Language 

Individual patterns usually address relatively atomic problems, i.e., on a granularity 
level where it is not rational to further decompose the problem into subproblems. To 
find a solution to a larger problem, several patterns need to be reviewed, possibly 
tailored, and combined as well as extended with designs specific to the current 
application project. Hence, a good pattern collection should comprise a structure 
showing how the individual patterns contribute to a larger problem. The term used 
for such a structure is pattern language. Alexander (1977) explains: “As in the case 
of natural languages, the pattern language is generative. It not only tells us the 
rules of arrangement , hut shows us how to construct arrangements — as many as we 
want — which satisfy the rules ” Figure 13.2 displays a pattern language in the form 



Improve 
management of 
ESI Human 
Resources" 





Improve 




Improve 


management of 




management of 


human resources 




human resource: 


at the 




at the individual 


organisational 




level 1 


level* 








Increase 
individuals 
responsibly for 
competency 
development 


Improve the 
knowledge 
sharing culture 


Transfer 
individual 
competence to 
orgamsdonal 
competence 




i 








Create 

knowledge 

sharing 

infrastructure 





improve the 




improve planning 


coordination of 




for unpredictable 


competency 




competency 


activities 




needs 



Fig. 13.2 An example of a pattern language for human resource management (Brash et al. 1999) 
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of goal hierarchy. It shows the different subgoals that need to be combined in order 
to achieve the top goal: “Improve management of ESI human resources.” In fact, 
this can be seen as a description of design intentions (modeled as goals) for relevant 
reusable fragments in the Concepts Model presented earlier. 

Patterns may have various types of relationships between them, for example, 
sub- or super-patterns depending on which way the refinement hierarchy is seen, 
hyperlinks indicating related concepts and patterns, as well as binary links with 
user-defined meanings. The choice of links used depends on the nature of connec- 
tion between patterns and the intended use of the pattern language. Furthermore, 
modern pattern languages are usually represented by a web interface, which allows 
linking with other relevant information sources that are not captured in the pattern 
format such as: glossary, picture gallery, and contact directory. 



13.4 Knowledge Reuse with Patterns 

There are two dimensions of reuse — design for reuse and design with reuse ; see 
Fig. 13.3. Both need to be addressed by the EM process and by the organizational 
structure supporting modeling. Without explicit organizational support knowledge 
will only be used sporadically and at best we can speak of so-called salvage reuse — 



Design for reuse 




Design by reuse 



Fig. 13.3 The two dimensions of reuse 
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modeling experts sift through old models in order to see if some solutions in them 
can be useful for the current project. 

By design for reuse we mean the systematic process of identifying valuable 
solutions in existing or newly created models and creating reusable components, 

i.e., patterns, from them. 

By design with reuse we mean the process of creating new organizational 
designs, enterprise models, by identifying existing patterns, adapting the solutions, 
and integrating them with the new solutions created in the project. 

In the remainder of this section we will discuss the pattern creating process and 
modeling with the use of patterns. 



13.4.1 The Pattern Creation Process 

Most often, patterns emerge from some existing EM project or positive experience 
that some experts consider worth generalizing and sharing with others. The pattern 
development process presented is based on the ELEKTRA pattern development 
process (Brash et al. 1999), which has been later refined in the project EKLar 
(Persson et al. 2008). The steps proposed here should be seen as general stages in 
the process of moving from a specific good solution to a pattern applicable in 
similar cases. These steps are: 

1 . Elicit candidate patterns 

2. Evaluate the suitability of each candidate and the collection as a whole 

3. Document and store each candidate pattern 

4. Verify each pattern 



13.4.1.1 Step 1: Elicit Candidates 

The objective of this step is to have list of potentially useful patterns and to describe 
each candidate pattern in sufficient detail to allow proceeding with its evaluation. 

The elicitation process can be divided into sub-steps. First, each candidate 
pattern must be elicited and its name must be defined. Then, the essential compo- 
nents of its template must be filled in, namely: the problem tackled by the pattern, 
the context in which the pattern is applicable, and the solution proposed by the 
pattern to solve the problem. No specific ordering needs to be followed when 
describing each component; their description is made in natural language and 
links to existing enterprise models can also be established. 

Eliciting patterns from existing 4EM models 

The initial source of knowledge is the repository of existing models. These can 
be models created in one or several EM projects. In principle any model that 
contains a valuable solution to a problem and is of adequate quality can be 
considered in this process. The following tips for analyzing models can be used: 
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• Patterns as processes: A sequence of processes describing how a business goal 
is successfully achieved as well as measured in terms of Information Sets. 

• Patterns as hierarchies of goals: A Goal Model may be a pattern in that it 
reflects the business experience in successfully defining and understanding its 
(or a part of its) goal hierarchy. 

• Patterns as concepts: A Concept Model showing how the business has success- 
fully designed the concepts of the domain. 

• Patterns as relationships between actors and roles: showing the dependencies 
between roles, their goals, and business processes they are associated with. 

• Patterns as enterprise models: Enterprise models showing a subsystem of the 
business. It may contain any combination of 4EM sub-models. 

Eliciting patterns through creation of new 4EM models 

It is traditionally assumed that patterns should not contain large model fragments 
because this reduces their understandability and cohesion, which in turn inhibits 
reuse. Hence, new models may need to be created especially to represent the 
solution proposed by the pattern. This can be done: 

• based on new insights and experiences gained, and from new evaluations of 
business practice, 

• when existing models are too detailed or specific, or 

• when models do not clearly relate to or solve specific problems. 

Additional information sources may also be used for creating patterns such as 
existing patterns in the repository (including the obsolete ones), business documen- 
tation, and information system designs. 



13.4.1.2 Step 2: Evaluate Suitability 

The potential patterns obtained as a result of step one need to be evaluated by 

domain experts so that their further development can be decided upon. The follow- 
ing criteria should be considered: 

Usefulness with respect to 

• Triviality : The degree to which the pattern addresses a problem that is of little 
importance to the business because the problem or solution is obvious. 

• Implementability : The extent to which the pattern is thought to be practical and 
implementable as well as compatible with business strategies; trade-offs should 
be taken into account. 

• Confidentiality: If the pattern discloses confidential or sensitive business infor- 
mation and pattern creation and sharing would compromise any confidentiality 
commitments, then the pattern creation is probably not justifiable. 
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Quality with respect to 

• Complexity : The complexity of a pattern can be estimated by considering the 
number of domain concepts and ideas it contains. In general, patterns should not 
be overly complex because this will most likely make the application 
cumbersome. 

• Generality : This concerns the abstraction level of the problem and proposal 
solution. We have found out in the evolution processes of patterns, that experts 
do not appreciate guidance on an abstract level without concrete examples and 
specific guidelines how to apply the solution in their organization (see, e.g., 
Rolland et al. 2000). Hence, the level of generality should not be too high. But it 
should not be too low either, because in that case the applicability will be low. 

• Under standability: This refers to the ease with which a pattern can be 
comprehended by the intended users. 

• External compatibility : The extent to which the pattern can be used by other 
users (projects or companies). This is influenced by the extent to which the 
pattern takes into account factors such as national or organizational culture, 
relevant technologies, and market conditions. 

Cost influenced by 

• Level of experience required for its use: This is influenced by the need to involve 
external experts. 

• Economic feasibility of the proposed solution: This refers to the expected cost of 
implementing the proposed solution. 

We suggest that the aforementioned criteria are discussed in a workshop setting 

with pattern authors and other relevant domain experts. The decision to further 

elaborate the pattern is based on the consensus achieved in the workshop. 



13.4.1.3 Step 3: Document Pattern 

At this stage the pattern template needs to be completed and the pattern extended 
with information about related patterns, documents, contributing authors, and 
hyperlinks to other relevant information sources. A part of this process might be 
adjustment of the pattern template according to the purpose of patterns and intended 
target audience. 

The pattern also needs to be stored in the pattern repository and related to other 
patterns in the pattern language. This might also require establishing links between 
patterns and some additional design artifacts such as code, Web services, or 
information system modules. 
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13.4.1.4 Step 4: Verify Pattern 

After a pattern has been fully documented and stored in the repository it should be 
verified by a broader group of the domain experts to ensure that the applicability 
and usefulness really is to the level envisioned by the pattern authors. This process 
can produce valuable feedback for improving existing patterns as well as serve as 
stimuli for creating new patterns. 



13.4.2 Use of Patterns in EM 



EM is a creative process and in this book we have advocated for the advantages of 
the participatory way of working. Creativity is contagious and fun for most people. 
But with respect to efficiency, creativity should not overshadow past successes. 
Good and proven solutions should therefore be used when appropriate. In Object- 
Oriented analysis and design, patterns become a common medium for transferring 
knowledge. In EM and business design in general this is not the case, at least not 
yet. There are companies that include patterns and knowledge reuse in the consult- 
ing services they offer. The challenge that we are facing is how to integrate reuse of 
patterns with the participatory way of working. Here we would like to propose the 
following dos and don’ts: 

Patterns should not be used if the purpose of the modeling session is to capture the existing 
situation in the company, e.g. to identify problems, change goals, or any other specifics of 
the organization. The goal in these cases is really to analyze the situation and not to arrive at 
a model as quickly as possible. 

Patterns should not be used if the purpose of the modeling workshop is to capture ideas 
and/or develop the vision for the company. The main focus in these cases should be arriving 
at something that the stakeholders consider valuable and worth pursuing. In such cases past 
experiences and best practices of other organizations can be discussed, but the main focus 
should be on developing the organization’s own. 

Patterns should be used if the purpose of the modeling session is to develop a concrete 
solution to a specific business problem. In this case the modeling facilitator should plan 
before the session for relevant patterns to use, at what points of the session the need might 
arise, and how to present the patterns to the participants if they are not familiar with them. It 
might be quite difficult to foresee how the session will evolve, but experienced facilitators 
are able to do this. What we would like to caution against is to present the patterns to the 
stakeholders as a matter of fact, which is contrary to the philosophy of participatory 
modeling that every idea in the model is discussed and that the model is owned collectively. 

Patterns should also be used after the modeling session in the process of refining the 
model. In this case the refinements should be presented to the stakeholders together with the 
patterns used. This can further enhance the stakeholder understanding of the model. 
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13.5 Examples of Pattern Use 

As discussed earlier, one of the challenges is to capture good and potentially 
reusable solutions in the existing models in order to support design for reuse. 
Considering the A4Y case presented in Chap. 8, there are quite a number of models. 
Some of the solutions are probably applicable in other cases as well. Consider the 
model fragment in Fig. 13.4; its main purpose is to elaborate on the measures for 
expanding marketing activities (goal 6) by defining a number of subgoals. 

Goal 6.1 deals with creating a more transparent marketing budget allocation. In 
principle we can imagine that this is a problem that other companies also face and 
that the solution here might be potentially useful. Therefore we have created a new 
pattern (see Fig. 13.5). 

Note that in the pattern we have introduced one more goal 1.3 aligning market- 
ing activities with the business strategy. This goal was not in the goal model we 
used as source for the pattern because this is what we did in the A4Y business 
development project. However, when developing patterns we have to consider 
more general application cases that do not have the same development situation 
in the background. The example pattern in Table 13.2 is simple and presents only 
common knowledge. It is included here only for example purposes. Patterns this 
simple are seldom useful as reported in (Rolland et al. 2000; Persson et al. 2008). 

Another dimension of pattern application is design by reuse — using existing 
patterns in order to make enterprise model more efficient and useful. For example, 
in the A4Y case we have modeled a simple purchase order for several products; see 
Fig. 13.5. 



Goal 6 

Expand marketing 
activities 

7 V 



supports 



Goal 6.2 

Use up to 10% of the 
last year’s turnover for 
marketing operations 



supports 

_x 



Goal 6.1 
Create a more 
transparent marketing 
budget allocation 



T - V 



4 — hinders — 



Problem 3 
Missing success 
monitoring of offline 
marketing operations 



supports 



/ 

Goal 14 

Introduce a central 
system for budget 
planning 



supports 

_A 



Goal 15 

Introduce analysis 
tools 



Fig. 13.4 A goal hierarchy addressing how to expand marketing activities 
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Concept 58 
E-Shop customer , 





Concept 6 
Product 



Fig. 13.5 Customer order modeled at a conceptual level 



Table 13.2 


A pattern based on the goal model of the A4Y case 


Name 


Transparent allocation of marketing budget 


Problem 


How to allocate marketing budget in an efficient and transparent way 


Context 


When company is in the process of change towards more efficient marketing and 
sales operations 


Forces 


Marketing success is difficult to monitor 
Different marketing actions may overlap 


Solution 


In order to create marketing budget in transparent way the following should be 

considered: 

— Introducing a central system for budget planning which would allow oversight of 
the planned costs for all marketing activities 

— Introducing analysis tools in order to see the results of the marketing activities such 
as, for instance, Google Analytics 

— Align marketing activities to companies business goals in order to be more efficient 
and cost effective 




From a conceptual point of view this model is satisfactory. But from the point of 
view of IS design and implementation, there is one problem — in reality it is possible 
to order more than one item of the same product, i.e., we need to specify quantity of 
the products ordered. We should consider that quantity is not attribute of a product 
because products are being sold on several orders with various quantities, and it is 
not attribute of a customer order because there can be several products ordered, 
each with different quantity. The solution to this is known as order line and is 
part of an analysis pattern for modeling an order (Fowler 1997); see Fig. 13.6. 
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Fig. 13.6 The general principle of using order, order line, and product 




Fig. 13.7 Customer order with line item modeled explicitly 



This pattern suggests introducing a new entity Line Item with attribute quantity. 
Applying this pattern to our model we would also have to introduce such a concept 
(see Fig. 13.7). 



13.6 Advanced Case of Pattern Application at Kongsberg 
Automotive 



Patterns have also been used beyond their initial purposes of managing reusable 
knowledge. Their characteristics of high modularity and cohesion have made them 
useful for configuring executable services, thus essentially making patterns execut- 
able. This section presents how Kongsberg Automotive AB, Sweden, used patterns 
from 2006 to 2008 within the EU-FP6 project MAPPER (Model-adapted Process 
and Product Engineering) for supporting collaborative engineering in networked 
manufacturing enterprises by capturing reusable organizational knowledge with 
Active Knowledge Models (AKM) (Lillehagen and Krogstie 2008). MAPPER 
developed c.a. 20, so-called task patterns, which included process, product, orga- 
nization structure, and resources for specific recurring organizational tasks, 
c.f. (Sandkuhl and Stirna 2008) for more details. The significant aspect of the 
MAPPER project is that the patterns developed were linked to IS components in 
the METIS tool and the AKM platform, which made the organizational solutions 
achieved by applying executable patterns. The more or less instant transition from a 
pattern to a running system was one of the advantages of the MAPPER approach. 
Figure 13.8 shows a pattern for establishing a material specification on the left and a 
functioning workflow system the behavior of which is defined by the pattern. 
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Fig. 13.8 A pattern in the Metis tool (above) and executed in the AKM platform (below) 



After the MAPPER project the AKM approach was commercialized by the 
Norwegian company Commitment AS, but it is too early yet to see if the approach 
will be a commercial success. 



Chapter 14 

Selected Enterprise Modeling Approaches 



Enterprise modeling approaches have been the subject of discussion and develop- 
ment in industry and academia during at least 30 years. Many approaches with 
different characteristics have been proposed and published; the 4EM method 
introduced in Chaps. 7-9 of this book is just one of them. This chapter briefly 
introduces some of these existing EM methods and compares them with 4EM. The 
purpose of this chapter is neither to provide an exhaustive list of approaches or 
methods nor is it to include all possible details and aspects in the comparison of 
4EM with other methods. The intention is rather to show that 4EM in many aspects 
is a typical or exemplary modeling method, i.e., it is easy to switch from 4EM to 
another method, since many concepts and perspectives used in 4EM also are 
available in other methods. 

This chapter will discuss selected EM methods. Each of the methods will be 
presented in a separate section covering the following aspects: 

• Origin/History: what is the origin of the approach and the history of its 
development? 

• Purpose: what is the main purpose the method was developed for and is used for 
in practice? 

• Elements of the approach: which of the elements of a method are provided by the 
approach, i.e., does it include a predefined modeling process, a notation, and/or 
an explicitly defined meta-model? 

• Model example: an illustrative example of a model developed with the approach 
under consideration is presented for most of the approaches. 

• Perspectives: what views or modeling perspective does the approach offer and 
are these perspectives comparable to 4EM? 

• Further readings: recommended literature and sources for additional information 

The approaches selected for this section by intention represent different focus 
areas in Enterprise Modeling. 
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• Active knowledge modeling (Sect. 14.1) aims at supporting work in enterprises 
with executable solution models which can be updated while working in order to 
always reflect the current status of enterprise knowledge. 

• ArchiMate (Sect. 14.2) is an established standard of the Open Group including a 
formal modeling language. 

• ARIS is an acknowledged approach to process modeling consisting of general 
notation rules, different functions, and a set of views on single parts of an 
enterprise to model (Sect. 14.3). 

• Design and Engineering Methodology for Organizations (DEMO) (Sect. 14.4) is 
an EM approach based on ontological foundations with an emphasis on captur- 
ing and modeling the operation of an organization in a way that is independent 
from implementation. 

• Multi-perspective enterprise modeling (Sect. 14.5) originates from information 
systems development and promotes the codesign of information systems as 
complex IT-artifacts with the organizational system to be supported. 

• Open model initiative (Sect. 14.6) aims at creating a community sharing models, 
modeling tools, and knowledge about modeling, which is similar to open source 
software communities. 



14.1 Active Knowledge Modeling and C3S3P 

14.1.1 Origin! History 

Active knowledge modeling (AKM) and many concepts and ideas attributed to this 
approach are based on work in Scandinavia in the beginning of the 1990s. One of 
the most important contributors to the approach, Frank Lillehagen, used early 
versions of active knowledge modeling in 1990 in automotive and aerospace 
industries and founded the company Metis which developed tool support for 
AKM. From 2000, the development of AKM was supported by a number of 
European research projects, which also contributed to the growth of the AKM 
community. Tool support, modeling notations, and method support are still under 
continuous development and used for industrial and public sectors and application 
domains. 

The concepts and methods support for AKM, supporting holistic design and 
continuous modeling and execution, is based on work in several EU projects from 
the area of networked and extended enterprises. An extended enterprise is a 
dynamic networked organization, which is continuously designed and executed as 
scope is expanded to reach a certain objective using the resources of the participat- 
ing cooperating enterprises. In order to support solutions development for extended 
enterprises, the EXTERNAL project developed a methodology for extended enter- 
prise modeling, which initially was named SGAMSIDOER. This methodology was 
further developed towards a solution delivery process denoted C3S3P, which was 
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used in the ATHENA (http://www.athena-ip.org/) and MAPPER projects. The 
latest version of the methodology is published in the book “Active Knowledge 
Modeling of Enterprises” (see Further Readings Sect. 14.1.6). 



14.1.2 Purpose 

The purpose of the approach is to develop active knowledge models, i.e., models 
which actively support roles and work processes in enterprises. These models can 
be updated while working in order to always reflect the current status of enterprise 
knowledge. Active knowledge models neither represent traditional “as is” nor “to 
be” situations, as they go beyond the scope of “to be” models by providing the 
actual implementation of the “to be”, the so-called solution model. Execution or 
enactment of such solution models requires an appropriate tool support capable of 
generating workplaces or work flows from models. In various industrial projects, 
the Metis tool or its successor Troux Architect™ was used for this purpose and 
extended for model execution. 

Active knowledge modeling combines and extends approaches and techniques 
from enterprise modeling and enterprise architectures. The knowledge needed for 
performing a certain task in an enterprise or for acting in a certain role has to 
include the context of the individual, which requires including all relevant perspec- 
tives in the same model. Using the knowledge is applying different reflective views 
on the knowledge model. Enterprise knowledge modeling aims at capturing reus- 
able knowledge of processes and products in knowledge architectures supporting 
work execution (Lillehagen and Karlsen 1999). These architectures form the basis 
for model-based solutions, which often are represented as active knowledge models 
(Lillehagen and Krogstie 2008). Krogstie and Jprgensen (2004) identify character- 
istics of active models vs. passive models and emphasize that “the model must be 
dynamic, users must be supported in changing the model to fit their local reality, 
enabling tailoring of the system’s behavior”. 



14.1.3 Elements of the Approach 

The AKM approach consists of a predefined modeling process, i.e., the C3S3P 
method, a number of best practices for active knowledge modeling and so-called 
model templates for different application domains, which are offered as part of the 
tool support. Examples of such model templates are CPPD for collaborative product 
development or ITM for IT management activities. 

The C3S3P method distinguishes between seven phases called Concept study, 
Scaffolding, Scoping, Solution modeling, Platform integration, Piloting in real 
projects, and Performance monitoring and management. The C3S3P phases roughly 
include the following: 
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• Concept Study: pre-studies are performed to investigate whether EM is a 
suitable and accepted way of developing executable solutions for the networked 
enterprise 

• Scaffolding 1 aims at creating shared knowledge and understanding among the 
participants of the project about the scope and challenges of the project. 

• Scoping: creation of executable models supporting the networked enterprise for 
a defined scope including all relevant dimensions required, like process, product, 
organization, or IT systems 

• Solutions Modeling: refining the scoping model by integration personnel, prod- 
uct structures, document templates, and IT systems required for using the 
enterprise model in an actual project 

• Platform Configuration: configure the solution models for use in the networked 
or extended enterprise by connecting the enterprise model to the platform used 
(see (Johnsen et al. 2007) for details on the MAPPER platform) 

• Platform Delivery: encompasses the roll-out of model-configured solutions 

• Performance Improvement by capturing indicators for process and product 
quality and using adequate management instruments. 



14.1.4 Model Example 

Active Knowledge Modeling and the C3S3P method do not include one specific 
modeling language or notation, but emphasize the need to represent mutually 
reflective views (see “perspectives” below) in such a way that the users of active 
knowledge models are supported in model use and enactment processes. Thus, a 
number of domain- specific modeling languages have been developed, like the 
Collaborative Product and Process Development (CPPD), which has a focus on 
manufacturing industries. Figures 14.1, 14.2, 14.3, and 14.4 show an excerpt from 
an active knowledge model developed for automotive industries in the research and 
development project MAPPER (see Johnsen et al. 2007). The purpose of the figures 
is to give an impression of what active knowledge models and typical notations 
look like. 

Figure 14.1 shows the process, organizational roles, and IT systems required for 
“develop new test method,” which is a task in automotive product development 
defining what test procedures for new materials to be used in specific product parts. 
The model excerpt visualizes in its center the process perspective of developing a 
new test method. The process flow consists of the steps “Check real need for new 
test method,,” “prepare draft,” “evaluation of test method concepts,” and “release 



1 The term scaffolding indicates the intention of this phase to create a firm structure supporting the 
development of a solution without making this structure a part of the solution — like in construction 
projects where the scaffold supports the construction of a building. 
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new test method.” These process steps are connected with typed relations, which 
are depicted as arrows. Usually, the type of relation is displayed by using a textual 
label. This is not shown in the figure in order to keep it readable. Above the process 
flow, objectives and documents which are input to the process are shown. 
The arrows indicate relationships between processes, roles, systems, and documents 
or objectives. 
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Fig. 14.1 Active knowledge model fragment for “develop new test method” 




Fig. 14.2 Fragment of the organizational sub-model 
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Below the process flow, the roles involved in the process are included (grouped 
at the left hand side) and the IT systems and tools are shown. The symbols used for 
roles, infrastructure resource, and documents are so-called process mechanisms, 
which basically serve as a proxy for the actual modeling element. Each process 
mechanism is linked by a specific relationship type to the actual modeling element. 

Figure 14.2 shows an excerpt from the organizational model. In the center, the 
organization unit “Engineering team” is depicted. The different roles of the engi- 
neering team are grouped around this organization unit. 

In Figure 14.3, a small part of the product model is shown. It shows the 
functional structure of a component to “deliver thermal seat comfort” which is 
broken down into its functional sub-components. On the right hand side of the 
figure, a number of relations are shown which lead to components implementing the 
functional subcomponent. These implementations are not included in the picture. 




Fig. 14.3 Fragment of the product sub-model 
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Fig. 14.4 Model element types of MEAF 
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Figure 14.4 shows other modeling element types available in this domain- 
specific modeling language. The visual modeling language applied was MEAF 
(METIS Enterprise Architecture Framework), which is an extension of the Generic 
Enterprise Modelling language (GEM). 



14.1.5 Perspectives 

AKM and the C3S3P method support the use of different perspectives when 
developing active knowledge models, but what perspectives to use is not generally 
standardized; it depends on the model template applied and the modeling purpose. 
However, there is a recommendation in AKM to follow the POPS* best practice. 
This best practice recommends to always evaluate at the beginning of a modeling 
project whether the following perspectives should be included in order to address 
all aspects of the problem at hand (Lillehagen 2003): 

• The process perspective (P) captures the work processes and tasks in the 
networked enterprise, 

• The organization perspective (O) includes all roles involved in the processes and 
their skills and competence profiles, 

• The product perspective (P) focuses on components, configuration possibilities, 
and dependencies of the product under consideration, 

• The systems perspective (S) includes the IT systems supporting work processes 
and product development, 

• Further perspectives (*) depend on the requirements of the enterprise under 
consideration and can include business objectives, customer requirements 
regarding the products, or key success factors. 

These perspectives are mutually reflective, i.e., each perspective influences 
content and meaning of the other perspectives, which is captured in relationships 
and dependencies between the elements of the perspectives. 



Table 14.1 Comparison of 4EM perspectives and AKM 



4EM perspective 


AKM perspectives according to POPS* 


Goals and 
problems 


Not explicitly defined. Can be added as “further perspective” 


Business 

processes 


Process perspective 


Actors and 
resources 


Organization perspective 


Concepts 


Not explicitly defined. Can be added as “further perspective” 


Business rules 


Not explicitly defined. In many model templates either represented as 
attribute/specification of business process or relationship types 


Technical 

components 


System perspective 


Not included in 
4EM 


Product perspective 
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Table 14.1 shows which perspectives in 4EM and in POPS* have similar or 
comparable meanings. 4EM does not contain an explicit product perspective. 
Product structures and related concepts can in 4EM be modeled in the concept 
model. 



14.1.6 Further Readings 



The following book contains a collection of all relevant information regarding 
active knowledge modeling: 

• Lillehagen F, Krogstie J (2008) Active knowledge modeling of enterprises. 
Springer, Berlin, Heidelberg 

The scientific foundations and the practical relevance of active modeling are 
subject to continuous improvement, for example by Frank Lillehagen at Commit- 
ment AS (Lysaker, Norway) and John Krogstie at the Norwegian University of 
Science and Technology (Trondheim, Norway). 



14.2 ArchiMate 
14.2.1 Origin/ H istory 

ArchiMate is a framework for describing enterprise architectures as well as tasks in 
enterprise architecture management. Based on the experiences from the first devel- 
opment projects between 2002 and 2004, Archimate has been established as a 
standard of the Open Group. Archimate is considered as a formal modeling 
language understandable by enterprise stakeholders. 



14.2.2 Purpose 

The focus of Archimate lies on capturing and visualization of value-added domains 
as well as existing interdependencies an enterprise is confronted with. ArchiMate 
supports modelers to address those stakeholders who lack domain-specific exper- 
tise. Additionally, models created with ArchiMate are suitable for automated 
analyses. 
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14.2.3 Elements of the Approach 



This section describes the ArchiMate framework with its core concepts, different 
functions, and the enterprise layers distinguished in ArchiMate. The section is 
concluded with a short overview to implementation and migration extensions. 
Each layer is illustrated with an example from a case study. 

The main architectural layers, representing the core of ArchiMate, are Business , 
Application , and Technology. Each layer has certain elements that are used to 
illustrate the domain- specific architecture. Additionally, there exists a class model 
of available elements, i.e., lower levels elements that provide support in the form of 
either services or functionalities for elements of higher levels. 

• Since the Business layer is the top level, it is responsible for modeling the entire 
course of business, e.g., interaction processes between customers and the 
enterprise. 

• One level below, the Application layer supports the Business layer by setting the 
focus on application services and the implementation of processes of an 
enterprise. 

• Last but not least, the Technology layer provides the infrastructure required to 
use the application services of the Application layer. Moreover, relationships 
between software and hardware are modeled on respective layer. 

The notation of ArchiMate differentiates between three types of elements: 
Active Structure Elements (Subject), Behavioral Elements (Predicate), and Passive 
Structure Elements (Object). Each and every element of the architectural layers 
outlined above is assigned to one of these types. Active Structure Elements are able 
to perform an action. In contrast, Passive Structure Elements are applied to a certain 
behavior that is defined by Behavioral Elements. In general, Passive Structure 
Elements represent either information or data objects. 

Figure 14.5 provides an overview of existing elements and their assignment to 
different layers. The Structural Concepts include all Active Structure Elements as 
well as the passive Business and Data Objects that are applied to support operative 
processes of an enterprise such as applications and business functions. In contrast, 
the Informational Concept includes those passive elements that manage interde- 
pendencies between operative processes and business goals. Finally, every Behav- 
ioral Element belongs to the Behavioral Concept. 

The following section introduces the different layers and show examples from a 
case study. 



14.2.4 Business Layer 

The Business layer mainly involves those elements applied in organizational 
structures. Moreover, products as well as services assigned to strategic levels 
belong to this layer. In general, business processes and especially value-adding 
processes represent the core elements of the Business layer. 
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Fig. 14.5 ArchiMate main elements (Josey et al. 2013) 



According to the structure illustrated in Fig. 14.5, there are six different struc- 
tural concepts, five behavioral concepts, and five informational concepts. The 
concept of Business Actors correlates with the concept of Business Roles. Never- 
theless, there is an important difference. The Business Actor represents an organi- 
zational unit that is able to either execute an action or show a certain behavior 
which is assigned to a Business Role. Business Actors are introduced whenever an 
individual person, department, or business unit needs to be modeled. In contrast, in 
case of illustrating a capacity that is able to execute a certain business process or 
function, Business Roles are applied. Taken together, Business Actors represent an 
identity of an organizational unit whereas a Business Role signifies a role in an 
enterprise linked to at least one task. 

In the case of scenarios where two or more Business Roles are needed in order to 
perform an action and retrieve a certain behavior, so-called Business Collabora- 
tions are applied. These define a joint capacity achieved by the collaboration of 
roles. Another element, the Business Interface , represents an interface for business 
services and the corresponding environment. A distinction is made between pro- 
vided interfaces, that make a specific functionality available, and required inter- 
faces, that are in need of a defined function. Additionally, for the purpose of 
managing a spatial distribution of aforementioned elements, ArchiMate 2.0 
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introduced a Layout element. Last but not least, there are passive Business Objects 
that are not able to perform a certain action. Instead, they are used to constitute 
different object types that are either written, read, or created by other elements. 

Besides presented structural concepts, there are different behavioral concepts such 
as Business Processes. These describe procedures that need to be adhered to in order 
to create products or services. A business process does not list particular details 
regarding the sequence of steps. Business Processes are invoked by elements of the 
Business layer that belong to the behavioral concept. An additional element of the 
behavioral concept is the Business Service that performs a specific service. A distinc- 
tion is made between internal and external business services. The former is not 
applied directly by customers. Instead, these provide a function inside an enterprise. 
In contrast, external business services are consumed by customers. Regardless of 
whether internal or external, business services are offered by the Business Interface. 

Business Functions are responsible for clustering elements according to defined 
criteria, e.g., supplies, competence, or knowhow. Business Events describe an inci- 
dent occurring either inside or outside an enterprise environment. They are able to 
both invoke and interrupt a business process. Furthermore, there are elements defin- 
ing the behavior of business collaboration elements, so-called Business Interactions. 
In contrast to Business Process and Business Function elements that are executed by a 
single Business Role, Business Interactions characterize at least two different roles. 

Finally, there are several informational concepts, e.g., Representations illustrat- 
ing information a business object consists of. In order to have an increased 
intelligibility of an actual task a business object or representation has, Meanings 
depict the purpose of respective objects in detail. Products as another concept 
represent either a certain product or a service of an enterprise where a customer 
needs to be able to acquire it. Moreover, contractual conditions to be observed by 
participating parties can be modeled; a correspondent agreement is modeled as 
Contract in formal, juridical, or informal way. Service level agreements (SLA) can 
be specified inside the contract. Values reflect the utility of both products and 
services. Furthermore, values can represent a financial value. An example for a 
Business Layer Model is illustrated in Fig. 14.6. 




Fig. 14.6 Business layer model example 
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14.2.5 Application Layer 

The main function of the Application layer is support of the Business layer with 
several application services. Business processes, functions, as well as interactions 
make use of these applications in order to fulfill their responsibility or task. As a 
consequence, this architectural layer considers the enterprise from the perspective 
of services needed for the realization of every process of the Business layer. 

A distinction is made between structural and behavioral concepts on this layer. 
From the structural perspective, the Application Component is the primary element 
representing a modular, universally usable, reusable, and exchangeable component 
of a software system. The functionalities are encapsulated and made available via 
one or more interfaces. An Application Interface provides an application service for 
the involved environment. A distinction is made between provided interfaces that 
grant access to a function and required interfaces, which are in need of a function. 
Similar to the business collaboration elements of the Business layer, there is an 
Application Collaboration element that aggregates at least two Application com- 
ponents in order to fulfill a certain task. In addition to aforementioned active 
elements, there is a passive Data Object which is subject of operations or applica- 
tions. Data objects represent the realization of Business objects on the Application 
layer. 

Beyond the presented structural concepts, there are three different behavioral 
concepts. Firstly, Application Functions cluster the performance achieved by 
Application components. Application functions represent the internal behavior 
whereas the external behavior is outlined by at least one Application Service. 
These Application services reveal the behavior of Application components in 
order to make these available for the environment and especially provide support 
for the Business layer. Last but not least, Application Interactions describe the 
behavior of Application Collaboration elements, i.e., the collective behavioral 
pattern of several Application components is expressed. Figure 14.7 illustrates an 
example of an Application Layer Model. 
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Fig. 14.7 Application layer model example 

14.2.6 Technology Layer 



The Technology layer provides elements for modeling services regarding the 
infrastructure, e.g., those being essential to run applications of the Application 
layer. Accordingly, several devices such as computers, servers, and operating or 
database systems belong to the Technology layer (Fig. 14.8). 

Similar to aforementioned layers, a distinction is made between structural, 
behavioral, and informational concepts. Introducing the structural concepts, a 
Node represents a system resource that is used in order to save, edit, and execute 
Artifacts. Moreover, Nodes are applied to model a holistic runtime environment, 
e.g., a database server. For the purpose of describing a Node more in detail, the 
related elements Device , representing a physical arithmetic unit, and System Soft- 
ware , a software component running on a Device, are introduced. More precisely, 
the processing power as well as memory capacity of Devices are used for storing 
and processing Artifacts. However, a Device might represent an independent 
element not being related to a specific Node. In contrast, System Software repre- 
sents the environment an Artifact is executed on. In general, there exists a peer-to- 
peer connection between a Device and the Software System. However, this element 
might be applied as a middleware acting as a mediator for two applications. 
Infrastructure Interfaces either provide access for Nodes and Application compo- 
nents to other Nodes ( provided interface) or define an interface another Node 
requires ( required interface). Furthermore, an infrastructure service might be 
made available for the environment it is located in. A Network is, as the term 
implies, a physical medium of communication that gives some indication of the 
kind of connection two or more Devices have. Accordingly, a Network is able to 
have several subnets and realize Communication Paths which are communication 
channels via Nodes and have the ability to exchange data. 
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Fig. 14.8 Technology layer model example 



Corresponding with Functions of aforementioned layers, the Infrastructure 
Function clusters behavioral elements of the Technology layer. Internal behavioral 
characteristics of a Node, which are invisible to the outside, are defined by 
Infrastructure functions whereas Infrastructure Services represent the external 
behavior. Accordingly, Infrastructure services make functions available for the 
environment in order to provide access, e.g., for applications components. 

Artifacts are a physical information units belonging to the informational con- 
cepts. As mentioned above, Artifacts are either created or edited during both 
software development and execution processes of a system. In general, an artifact 
represents a specific element of concrete scenarios such as documents, scripts, or 
executable data. An Artifact is applied for the realization of Data objects and 
Application components or is related to several Nodes. 



14.2.7 Relationships 



ArchiMate offers a set of relationships that connect single elements and create 
cross-layer dependencies between the layers described above. In general, three 
types of relationships can be classified. Structural Relationships are used for 
describing the structural coherence between single elements. Dynamic Relation- 
ships represent dependencies between concepts, often time -based. The last type, 
Other Relationships , contains all relations that cannot be allocated to one of the first 
two categories (Josey et al. 2013, p. 51). 

Structural Relationships consist of seven subtypes. One of the most commonly 
utilized relationships is the Association. It can be used when no more specific type 
can be found. Access represents the access to business or data objects. Used By 
models the usage of services and the access to interfaces. Realization connects an 
unspecific, logical element with a more concrete one for its actual implementation. 
Assignment links Behavioral Concepts with Structural Concepts and roles with 
concrete actors. Aggregation illustrates that an element groups several other ele- 
ments. Here, every element can be part of multiple aggregations. Composition 
indicates that an element consists of a number of other elements. In contrast to an 
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Fig. 14.9 ArchiMate structural relationships 
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Fig. 14.10 ArchiMate dynamic relationships 
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Fig. 14.11 ArchiMate other relationships 



aggregation, every element can only be part of one composition (Josey et al. 2013, 
pp. 51-53). Figure 14.9 illustrates the seven sub-types for the Structural 
Relationships. 

Dynamic Relationships can only be subdivided into two types (Fig. 14.10). The 
Flow represents an exchange between elements, e.g., the exchange of information 
and data. Triggering describes casual or temporal dependencies between elements 
(Josey et al. 2013, pp. 53-54). 

The group of Other Relationships contains three relations (Fig. 14.1 1). Grouping 
indicates that elements, from the same type or different types, can be collected by 
using a common characteristic. Junction applies for connecting relations of the 
same type. Specialization illustrates the fact that one element is a special form of 
another one (Josey et al. 2013, pp. 54). 



14.2.8 Motivation Extension 

This extension adds motivational concepts to ArchiMate. These concepts can be 
used to justify the way of how the enterprise architecture is designed. For instance 
factors that influence the enterprise, its behavior, and design are considered to find 
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Fig. 14.12 ArchiMate 
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arguments for architecture design decisions. These influencing factors can be 
stakeholders , drivers , and assessments (Fig. 14.12). 

Stakeholders are all economic groups that are involved in the respective enter- 
prise in any way. Thus, they are interested in the success of the architecture design 
process and its outcome. Stakeholders are able to set, change, and emphasize goals. 
A Driver is used to represent specific influences on the enterprise that cause changes 
in the organization. These can be internal ones like stakeholder interests or external 
ones like legislation changes. In order to identify and understand the drivers, an 
Assessment for each of them has to be conducted. That way, strengths, weaknesses, 
threats, and opportunities concerning single driver scopes can be revealed (Josey 
et al. 2013, p. 60). 

The other dimension of motivational concepts is represented by the parameters 
of goals, requirements, constraints, and principles. They complement the influenc- 
ing factors mentioned above. 

A Goal expresses a state intended by a stakeholder (Josey et al. 2013, p. 60). 
Through adequate setting of goals, drivers can be influenced in a positive way. 
Requirements are challenges that have to be met to realize a certain goal (Josey 
et al. 2013, p. 61). That way, they represent the initial situation in the process of target 
compliance. A Constraint describes an unalterable restriction that applies during the 
whole realization process, e.g., time or budget restrictions (Josey et al. 2013, p. 61). 
Finally, a Principle is a general guideline that has to be adhered to during the realization 
of set goals. In contrast to requirements, they are more abstract and hence they have to 
be implemented by specific requirements before using them in architecture design. 

For modeling relations between single motivational elements and their relations to the 
core elements, ArchiMate provides three different types of relationships (Fig. 14.13). 
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Fig. 14.13 ArchiMate motivation extension relationships 
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Fig. 14.14 ArchiMate implementation and migration extension elements (Josey et al. 2013) 

The Aggregation expresses the subdivision of an element into multiple 
sub-elements which together build the superior element (Josey et al. 2013, p. 61). 
Realization models the aspect that one element is realized by another one, e.g., a 
goal can be realized by a principle, a constraint, or a requirement. Influence shows a 
relation between two elements, in which one has influence on the other. It is 
distinguished between positive and negative influence. 



14.2.9 Implementation and Migration Extension 

The Implementation and Migration Extension provide elements that can be used 
for, as the name implies, implementation and migration of an architecture. With the 
help of this extension, modeling projects, supporting programs, or project manage- 
ment aspects can be approached (Josey et al. 2013, p. 65). 

The extension contains four concepts: Work package, Deliverable, Plateau, and 
Gap. A central concept is the Work Package. It embodies a defined set of actions 
that are necessary to complete a certain goal within a given time frame. Each work 
package produces a Deliverable. The implementation of the desired architecture is 
such a deliverable, whereas deliverables usually have much smaller scopes; a 
software product and a report are deliverables too. A Plateau represents the single 
intermediate stages during the architecture development process. As this process is 
incremental, every architecture state from the initial situation to the final architec- 
ture is depicted by a plateau. The last concept, the Gap , describes the differences 
between two consecutive plateaus, i.e., it contains all modifications that were made 
to create a new architecture stage from an older one (Fig. 14.14) (Josey et al. 2013, 

p. 66) 
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Table 14.2 Comparison of 4EM perspectives and ArchiMate 



4EM perspective 


ArchiMate 2.0 layers and objects 


Goals and problems 


ArchiMate motivation extension elements (goal, constraint, driver, 
requirement) 


Business processes 


Business layer (process) 


Actors and 
resources 


Business layer (actor, role, product, contract) 


Concepts 


Not explicitly defined. 


Business rules 


ArchiMate motivation extension elements (Principle) 


Technical 


Application and technology layer (component, function, service, 


components 


interface) 



1 4.2.1 0 Conclusion 

ArchiMate offers an enterprise architecture modeling language to the user. It offers 
a holistic approach, covering the whole organizational structure of an enterprise. 
This is achieved by dividing the architecture development into three layers — 
Business, Application, and Technology — which built on each other with Business 
as the highest level. The modeling process is enriched by extensions that add 
additional factors like motivational or implementation aspects. 

Compared to 4EM, ArchiMate uses a different modeling approach. While 4EM 
divides the modeling into several sub-models, each covering a different perspective 
on the enterprise and its organization, ArchiMate structures the enterprise into three 
separate layers, each combining various perspectives. Furthermore, ArchiMate 
provides modeling elements, which are central in 4EM (goals, constraints, etc.), 
only as extensions to the main framework. Nevertheless, after a complete and 
detailed implementation, both methods should deliver similar results. 

To conclude, ArchiMate may serve as an alternative to 4EM. Due to a different 
modeling approach, it may be applicable in situations where 4EM is not appropri- 
ate. On the other hand, 4EM in many Enterprise Modeling projects has advantages 
compared to Archimate, for example, if participatory modeling is required or 
ill- structured problems have to be addressed (Table 14.2). 



14.2.11 Further Readings 



The following pocket guide provides a nice entry point to ArchiMate literature and 
summarizes the most important concepts and ideas: 

1. Josey A et al.; The Open Group (2012) ArchiMate 2.0 — A pocket guide. Van 
Haren. 
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14.3 ARIS 

1 4.3.1 Origin! H istory 

ARIS (Architecture of Integrated Information Systems) has its origin in the aca- 
demic research of Prof. August- Wilhelm Scheer in the 1990s. Scheer was during 
many years with the Saarland University in Saarbriicken (Germany), which still has 
strong research groups in the area of ARIS and its related techniques. ARIS offers a 
methodological framework and different approaches and tools for analyzing pro- 
cesses and other aspects of enterprises (see below). Scheer successfully converted 
these methods and tools into commercial products, which currently are in the 
product portfolio of Software AG. ARIS and EPC (see below) are widely used in 
industry as means for business process modeling and management. 



14.3.2 Purpose 

The ARIS approach (Scheer and Nuttgens 2000) includes general notation rules, 
different functions, and a set of views for enterprise modeling which often are 
depicted as the “ARIS house” (see below). Furthermore, ARIS provides a method- 
ological framework to support process modeling activities, which also offers the 
possibility to describe the dynamics of the business processes. A modeling lan- 
guage known as Event-driven Process Chains (EPC) is part of ARIS. EPC are 
widely used in industry and supported by a large number of modeling tools. 



14.3.3 Elements of the Approach 

The following section describes the ARIS framework with its general notation 
rules, different functions, and the set of views used during modeling. Each view 
is illustrated with an example from the A4Y case study (Chap. 7). The section is 
concluded with a short introduction to the ARIS phases (so-called description 
levels) and the ARIS House. The core modeling language approach used in ARIS 
are Event-driven Process Chains (EPC). Figure 14.15 illustrates the basic notation 
of EPC. 

The main components for the purpose of describing business processes are 
events and functions. The former is a passive element and characterizes the 
occurrence of a defined state that has an influence on the further process. An 
event is able to trigger a function inside as well as outside a company. However, 
functions perform a change in the state of a certain object. In other words, an active 
conversion from an input to an output is realized. 
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Fig. 14.15 EPC notation overview 

Aside from the two main components event and function, EPC use additional 
elements such as information objects, organizational units and systems for model- 
ing organizational structures, IT systems, and documents of information sets. 
Last but not least, an element serving as a navigation aid, the so-called process 
path, is used for the purpose of showing the connection to other processes. 

Logical relationships and different types of connectors support the modeling of 
business processes. Information flows represent a relationship between functions 
and either input or output data upon which the function executes a read, change, or 
write operation. Control flows , however, create a chronological sequence as well as 
interdependencies between functions, process paths or logical connectors. 

ARIS distinguishes between four different views: 

• Function View: ARIS distinguishes between two possible representations: func- 
tion tree and goal diagram. A function tree is responsible for indicating the 
complexity and hierarchy of objects and corresponding relationships. In com- 
parison, the goal diagram defines different business goals and creates a hierar- 
chical structure among these. 

• Data View: This view contains two content perspectives: information and data. 
The elements of this view are usually modeled by using entity-relationship 
models (ERM) with their components: Entities, Attributes, and Relations. 
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Fig. 14.16 ARIS function tree 



• Organization View: The organization view of ARIS focuses on the organiza- 
tional structure of an enterprise describing how the parts of the enterprise, the 
organizational units, are organized and how they are related to each other. 

• Control Process View: This view captures connections between events and 
functions representing the flow of the process. In contrast to the static functional 
and data models, the control view focuses on procedural (time-based, logical) 
aspects describing coherences of functions. 



14.3.4 Examples 

This section presents some examples for the different ARIS views. The purpose of 
the examples is to illustrate the ARIS notation. Figures 14.16 and 14.17 show 
examples from the function view: function tree and goal diagram. 

As already indicated above, the data view in ARIS primarily relies on entity- 
relationship models (ERM), but adds additional components and modeling possi- 
bilities to ERM. Figure 14.18 shows an example data model for a product from the 
A4Y case study. 

An enterprise’s organization can be divided into the organizational structure on 
the one hand and the operational structure on the other hand. The organizational 
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Fig. 14.17 ARIS objective diagram 




Fig. 14.18 ARIS data view 
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Fig. 14.19 ARIS organization view 

structure describes how the parts of the enterprise, the organizational units, are 
organized and how they are related to each other. The operational structure 
describes how tasks and processes are allocated to organizational units and sets 
timeframes as well as facilities. The organization view of ARIS focuses on the 
organizational structure of an enterprise. Therefore, it can be subdivided into 
particular positions or subunits. Figure 14.19 shows an example model depicting 
the top level organizational structure of the case study enterprise. 



14.3.5 Control (Process) View 

In contrast to the static functional and data models, the control view focuses on 
procedural (time-based, logical) aspects describing coherences of functions. In 
general, the basic version of EPC is applied in order to model a consistent process 
flow with basic elements such as functions and events. Figure 14.20 shows an 
excerpt of an EPC. 

Furthermore, the ARIS framework uses description levels and the ARIS House 
as illustration of the overall approach: 

• Description levels: ARIS provides three phases of the modeling process called 
description levels that are used to depict the typical course of a software project 
(requirement definition, design specification, implementation). 

The ARIS House: The ARIS house contains the four views and the description 
levels in order to provide an illustration and overview of the general ARIS 
approach. The ARIS House approach is depicted in Fig. 14.21. 



14.3.6 Perspectives 

ARIS provides an approach to model the architecture of integrated information 
systems within enterprises. Through its division into different views, it covers all 
organizational parts that are involved in the information system design and usage. 
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Fig. 14.20 ARIS control view 
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Table 14.3 Comparison of 4EM perspectives and ARIS 



4EM perspective 


ARIS views and EPC concepts 


Goals and 
problems 


Function view (goal diagram) 


Business processes 


Function view (function diagram, EPC) 


Actors and 
resources 


Organization view (e.g., organizational chart, organizational unit, person) 


Concepts 


Not explicitly defined as a view. Can be partly be captured with the Data 
View (ERM) 


Business rules 


Control view (EPC) 


Technical 

components 


Not explicitly defined as a view. Can be captured in EPC. 



The three consecutive description levels reflect the typical course of a software 
development project. Many aspects of ARIS can also be found in other Enterprise 
Modeling approaches. 

One of the similarities between ARIS and 4EM is to reduce complexity in the 
modeling process by using different sub-models, which in ARIS are considered as 
views and in 4EM as perspectives. However, the purpose and the content of the 
sub-models are different, as illustrated in Table 14.3. The most important difference 
is probably the focus of ARIS on control flows (as modeled by EPC) whereas 4EM 
considers all perspectives as equally important. 



14.3.7 Further Readings 



Scheer A-W, Nuttgens M (2000) ARIS architecture and reference models for 
business process management. Springer, Berlin, Heidelberg 



14.4 DEMO 
14.4.1 History 

The Design and Engineering Methodology for Organizations (DEMO) is an EM 
approach for capturing, representing, and analyzing business processes and 
transactions. 

DEMO is based on the theoretical foundations that stem from the Language 
Action Perspective (Flores and Ludlow 1980). The concept of analyzing what 
people do when communicating and how that influences the information system 
specification was a significant innovation at that time, which influenced a number of 
theoretical contributions to the area of information system engineering. 
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DEMO originally was an acronym for Dynamic Essential Modeling of Organi- 
zations. It was developed at the Delft University of Technology by Professor Jan 
Dietz (1996). The current version of the DEMO is denoted Design and Engineering 
Methodology for Organizations as published in (Dietz 2006). DEMO is being 
further developed and maintained by the Enterprise Engineering Institute, The 
Netherlands, and over the years has built a community of researchers and practi- 
tioners under the auspices of the CIAO! Network (http://ciaonetwork.org/). 



14.4.2 Purpose 

The purpose of DEMO is to offer an EM approach based on sound ontological 
foundations. A particular emphasis is on capturing and modeling the operation of an 
organization in a way that is independent from implementation. The resulting 
models can be called Enterprise Ontologies. This in turn contributes to the enter- 
prise model adhering to the following quality criteria as defined in (Dietz 2006): 
coherent, consistent, comprehensive, concise, and essential. 



14.4.3 Elements of the Approach 

DEMO is based on the theory for performance in social interaction proposed in 
(Dietz 2006), called the T'-theory. According to this theory organizations are social 
systems consisting of humans or subjects in which case it is of particular impor- 
tance to consider their interaction. The subjects perform two kinds of acts: 

• Production acts (P-acts). P-acts are used to model how the subjects contribute to 
bringing about the goods or services that are delivered to the environment. 

• Coordination acts (C-acts). C-acts are used to model how subjects enter into and 
comply with commitments towards each other regarding the performance of 
P-acts. 

The effect of performing a C-act is that both parties involved — the performer 
and the addressee of the act — get involved in commitments about the bringing 
about of the corresponding P-act. Both act types occur as steps in a generic 
coordination pattern, called transaction (see Fig. 14.22). 

A transaction (shown in upper right corner) has three phases: 

• The order phase (O -phase), during which the initiator and the executor negotiate 
for achieving consensus about the P-fact that the executor is going to bring 
about. The main C-acts are the request and the promise. 

• The execution phase (E-phase), during which the P-fact is brought about by the 
executor. 

• Result phase (R-phase), during which the initiator and the executor negotiate for 
achieving consensus about the P-fact that is actually produced. The main C-acts 
are the state and the corresponding accept. 
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Workfbw Loop 



Basic Transaction Pattern 




Molecular Building Blocks 



Atomic Building Blocks 



Fig. 14.22 Building blocks of an enterprise ontology (Ettema and Dietz 2009) 



The transaction described above may be more complex as discussed in (Dietz 
2006). The notation for representing the basic transaction pattern is shown on the 
lower right side of Fig. 14.22. A C-act and its resulting C-fact, and likewise, a P-act 
and P-fact, are represented by one symbol each. The lower left side of the figure 
represents the complete transaction pattern by one symbol — the transaction symbol. 
It consists of a diamond (representing production) embedded in a disk (representing 
coordination). Transaction types and actor roles are the molecular building blocks 
of business processes and organizations, the transaction steps being the atomic 
building blocks. 

DEMO is based on the principle that humans have three abilities — the forma, the 
informa, and the performa ability. They are used both in C-acts and in P-acts 
(Table 14.4). 

This distinction of human abilities motivates the layered view on organizations. 
As discussed in Dietz (2006) organizations have three aspects: 

• D-organization dealing with datalogical problems such as the syntactic aspects 
of information (data) and the operations on data and documents, e.g., storing, 
copying and transporting. 
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Table 14.4 Three human abilities in terms of coordination and production, adapted from (Dietz 
2006) 



Coordination 


Human ability 


Production 


Exposing commitment 
(as performer) 

Evoking commitment 
(as addressee) 


performa 

(Latin for “through 
the form”) 


Ontological action (deciding, judging) 


Expressing thought (for- 
mulating) 

Educing thought 
(interpreting 


informa 

(Latin for “in the 
form”) 


Infological action (reproducing, deducing, 
reasoning, computing, etc.) 


Uttering information 
(speaking, writing) 
Perceiving information 
(listening reading) 


forma 

(Latin for “form”) 


Datalogical action (storing, transmitting, 
copying, destroying, etc.) 




Fig. 14 .23 The three aspects of an organization and the ontological model 



• I-organization dealing with infological problems: the semantic aspects of infor- 
mation and computational operations. 

• B -organization dealing with new and original facts, i.e., facts that change the 
business world, such as decisions and judgments. 

According to DEMO the ontological model of an organization should focus on 
the B -organization (see Fig. 14.23). Such a model should consists of four aspect 
models: 
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• The Construction Model representing the actor roles and transaction kinds 

• The Process Model representing the business processes and business events 

• The State Model representing the business objects and business facts, and 

• The Action Model representing the business rules. 

Notations for the Construction Model and Process model will be shown in the 
next part of this section. DEMO uses ORM — Object Role Modeling (Halpin 2001). 
The Action model consists of action rule specified in a pseudo-algorithmic lan- 
guage described in (Dietz 2006). 

14.4.4 Model Example 

A large collection of cases are available on the Enterprise Engineering Institute 
Web site (http://www.demo.nl/practical-case-studies). 

This section shows a few examples from a case used in (Ettema and Dietz 2009). 
The case is about the process of registering an imported car in The Netherlands at 
the Dutch Tax Department. This process is associated with paying a special kind of 
tax called BPM. After analyzing the background description of the case and 
applying the transaction pattern, three transaction types are identified: T01 — the 
import of a car, T02 — payment of the VAT on the car, T03 — the admission of a car 
to the Dutch road network, and T04 — the payment of the BPM tax. In this context 
car import and admitting it to the road network should be seen as two different 
issues, and in principle one could do the first but not the second. Considering this 
Actor Transaction Diagram Shown in Fig. 14.24 can be developed. This together 
with the transaction result table (Table 14.5) constitute the Construction Model. 
Since both parts of the process are disconnected only the part associated to T03 and 
T04 is elaborated in the Process Model (see Fig. 14.24). CA03 and CA04 are 
fulfilled by a private person. RDW (The Netherlands Road Transport Department) 
fulfills actor role A02 (road network admitter). Tax Office (Belastingdienst) is 
performing T04/ac. The dashed arrow from T04/ac to T03/ex means that the 
RDW has to wait until the BPM tax has been paid before deciding to admit a car 
to the road network (Fig. 14.25). 



CA0 Car I eh port 




Fig. 14.24 Actor transaction diagram for the car import case (Ettema and Dietz 2009) 







262 



14 Selected Enterprise Modeling Approaches 



Table 14.5 Transaction result table of the car import case 



Transaction type 


Transaction result 


T01 importing 


R01 Import 1 has been performed 


T02 import VAT PAYMENT 


R01 Import VAT for import 1 has been paid 


T03 admitting 


R03 Admission A has been started 


T04 BPM tax payment 


R04 BPM tax for admission A has been paid 



CA03 admission 
applicant 



CAD Car Import 



CAM bpmtax payer 
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[Private Person] 



Krol 

J™A 



[ROW] 



T03. H 



[ROW] 



JT04 

XKa 

[RDW] 



T04 

ac 



F3 



[ Bela sti ngd ie nst] 



pT03 ’’ 








''T03' 


L?v 








^ St ,• 



[RDW] 



T04 



[Private Person] 



' T04 

[Private Personl 

rA 
* ™ I 

A 

[Private Person] 



hJLA 



Fig. 14 .25 Process model for the car import case (Ettema and Dietz 2009) 

14.4.5 Perspectives 

As discussed previously DEMO supports the following aspects — the Construction 
Model representing the actor roles and transaction kinds, the Process Model 
representing the business processes and business events, the State Model 
representing the business objects and business facts, as well as the Action Model 
representing the business rules. The foundations of the methodology make these 
perspectives closely interlinked, which is one of the advantages of DEMO in 
comparison with other approaches where different models and modeling perspec- 
tives may be more or less only “talked” together (Dietz 2006). 
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Table 14.6 Comparison of 4EM perspectives and DEMO 



4EM perspective 


DEMO perspectives 


Goals and problems 


Not explicitly defined 


Business processes 


Process model and construction model 


Actors and resources 


Construction model, actor transaction diagram 


Concepts 


State model using ORM 


Business rules 


Action model 


Technical components 


Not explicitly defined 



Table 14.6 shows, which perspectives in 4EM and in DEMO have similar or 
comparable purposes. 



14.4.6 Further Reading 

The most thorough source about DEMO is the book by Jan Dietz (2006). There also 
are a large number of scientific publications available. To begin exploring the world 
of DEMO, we would like to suggest the following. Ettema and Dietz (2009) provide 
a comparative evaluation of ArchiMate and DEMO. Albani and Dietz (2011) 
demonstrate the suitability of DEMO for information system development. Caetano 
et al. (2012) present an approach to analyze the consistency and completeness of 
process models according to the principles of the \p-theory and the underlying 
concept of business transaction. In addition the website of the Enterprise Engineer- 
ing Institute has a large collection of publications such as case studies, DEMO 
specifications, as well as research publications. 



14.5 Multi-perspective Enterprise Modeling 
1 4.5.1 Origin/ H istory 

Development of the Multi-perspective Enterprise Modeling (MEMO) method 
started in the 1990s in Germany in an academic context. The initiator and still 
main developer and driving force behind MEMO is Ulrich Frank, now professor at 
the University of Duisburg — Essen in Germany. From its very origin, MEMO 
incorporated several perspectives and emphasized the importance of them. A 
perspective in MEMO is used to satisfy the intended model user’s perspective, 
i.e., to provide the specific goals and capabilities required by the user, and to 
represent this user perspective in an appropriate way in the enterprise model. 
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In addition to work on conceptualizing perspectives from a modeling point of 
view and on identifying what perspectives typically are required, a meta-model, 
modeling languages, and tool support were developed. MEMO has been used in a 
variety of research and development projects, most of them driven by or with 
participation of Ulrich Frank and his team. MEMO specifications are publicly 
available. The method is not a commercial product. 



14.5.2 Purpose 

The intention of MEMO is to support the modeler in designing and analyzing 
enterprise models. The method’s purpose on the one hand side is to promote 
communication and collaboration between the different participants in the model 
design and analysis process, which includes providing a common reference. On the 
other hand the model has to promote control and change, which refers to reliable 
development processes and adaptability to change in the modeling subject. 

MEMO was developed in the context of information systems development and 
promotes the codesign of information systems or software systems as complex IT 
artifacts with the organizational system which has to be supported. 

The codesign requires views and abstractions for the business professionals 
involved in the organizational system and the technology professionals engineering 
the software systems. These views and abstractions are accounted for in different 
perspectives of an enterprise model, which basically are represented in specific 
conceptual models. Thus, an enterprise model “comprises conceptual models of 
software systems (...) that are integrated with conceptual models of the surround- 
ing action systems” (Frank 2013). 

14.5.3 Elements of the Approach 

MEMO consists of a high-level conceptual framework, domain-specific modeling 
languages, and methods and tools accompanying these languages. The high-level 
framework primarily consists of 

• Perspectives offering a specific abstraction of the enterprise for a certain stake- 
holder group starting from the generic perspectives “strategy,” “organization,” 
and “information system,” more specific perspectives for stakeholder groups can 
be developed 

• Aspects, which are used to further detail the perspectives. Typical aspects are 
goal, process, structure, or resource. 

Each perspective is associated with a set of domain-specific modeling languages 
(DSML) capable of expressing the aspects. The MEMO modeling language(s) are 
all specified with a common meta-modeling language, the MEMO MML, which 
leads to a language architecture: the meta-meta-model is used to define the meta- 
models for the domain- specific modeling languages for the different perspectives. 
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These DSML in turn is used to capture the actual conceptual models of the 
perspectives. Due to the existence of a meta-meta-model, other DSML can be 
defined which allows for adaptation to the modeling purpose at hand. The DSML 
defined by MEMO are the strategy modeling language SML, the organization 
modeling language OrgML, the goal modeling language GoalML, the IT infra- 
structure modeling language ITML, and the object-oriented modeling language 
OML. In addition to those, various language extensions exist, e.g., for modeling 
decision scenarios or IT security. 

Method support in MEMO initially focused on information system development 
as a codesign activity with developing organizational structures and processes. 
During the last years, methods for specific purposes were added, like a method 
for IT management or IT audit risk management. The methods are described in 
separate publications. 

The tool environment for MEMO is called MEMO center. It implements the 
MEMO language architectures and comprises a meta-model editor and an extensi- 
ble set of model editors for DSML. 

The meta-model editor does not only allow for specifying meta-models and 
corresponding notations. It also enables generating respective editors. 



14.5.4 Model Example 

This section will show two examples to illustrate the MEMO approach. As indi- 
cated above, MEMO includes the general possibility to define domain- specific 
modeling languages and four DSML are already defined as part of MEMO: the 
strategy modeling language SML, the organization modeling language OrgML, the 
IT infrastructure modeling language ITML, and the object-oriented modeling 
language OML The first example model addresses process modeling with 
MEMO. Within MEMO, process modeling is part of the organization modeling 
language (OrgML). Figure 14.27 shows a small process model in OrgML and 
Fig. 14.26 presents the modeling elements and symbols used in this small example. 
Regarding the modeling elements, 

OrgML includes elements for modeling processes, events, exceptions, and control 
flows. The language distinguishes five different process types, three of which are 
shown in Fig. 14.26: the manual process (performed by a human actor without 
IT-support), the computer-supported process (performed by a human actor with 
IT-Support), and the automated process (performed by a computer). Additionally, 
OrgML also supports the process type “any process” (if the exact process type is not 
known) and any external process (performed by an external human actor or com- 
puter). With respect to events, the language allows for modeling events related to time 
aspects (point in time, time interval), change of information objects (create, modify, 
delete information object; unspecified change), and notification events related to 
human actors (asynchronous via traditional communication means or via electronic 
means, synchronous, not specified) or software (publish, poll, not specified). 
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Fig. 14.26 Selected OrgML elements for business process modeling 
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Fig. 14.27 MEMO example model “order process management” 

The different aspects are represented in basic symbols which can be combined when 
modeling events. Due to the many different possibilities to combine time, change, and 
notification aspects, the language has 96 different event symbols. Four of these 
symbols are shown in Fig. 14.26: the start event (begin of a process), the stop event 
(end of a process), an event caused by a change in an information object, and an event 
caused at a point in time. 

In order to model the control flow, the language allows for sequential flow of 
processes, branching in alternative flows, and concurrent flow of processes. 
Branching is modeled by using one of four different modeling elements indicating 
that an exclusive choice between the branches following the element has to be 
made. Figure 14.27 shows two of these elements: branching by “manual decision” 
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(made by a human actor) and “automated decision” (made by an IT system). If 
parallel process flows were modeled or if branches of processes can run in parallel, 
synchronization of these concurrent paths is necessary. This is possible by using 
“AND” and “OR” modeling elements for conjunctive synchronization (all parallel 
paths have to terminate before the following process is started) or disjunctive 
synchronization (the following process is started after the first parallel process 
finished). Figure 14.26 does not show any symbols for exceptions, since there is 
no exception included in the example in Fig. 14.27. OrgML has three basic classes 
of exception (cause, effect, detection) with in total 1 1 basic exception types. 

The business process shown in Fig. 14.26 describes an order process manage- 
ment which begins with the start event “order received.” The following computer- 
supported process “check credibility” is followed by a manual branching decision 
where a human actor decides whether the credibility is sufficient or not. If the 
credibility is not sufficient, the upper path is taken: the “information change” event 
“credibility insufficient” (i.e., the decision is entered into a computer system which 
causes a change in the information object representing the customer’s credibility) is 
followed by the process “inform customer” performed by the “sales assistant.” This 
again results in a manual decision, which either leads to “order rejection” and the 
termination of the process or to the “information change” event “credibility ok.” In 
the latter case, the process flow is merged with the alternative branch following the 
“check credibility” process at the beginning of the business process. In the 
remaining part of the example, the use of conjunctive and disjunctive synchroni- 
zation also is illustrated. 

The second example addresses modeling of organizational structures. Again, 
this is part of OrgML and illustrated in two figures: Fig. 14.28 shows selected 
elements of the graphical notation and Fig. 14.29 shows an example. The graphical 
notation includes elements for organization units, positions, and roles. Furthermore, 
relationships and interactions between organization units, positions, and roles can 
be expressed, and constraints can be defined. 
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Fig. 14.28 Selected OrgML elements for organization structure modeling 







268 



14 Selected Enterprise Modeling Approaches 




15 



Fig. 14.29 MEMO example model “functional organization” 



OrgML offers a rich set of elements for modeling organizational entities, which 
includes different symbols for positions, like positions with technical background, 
management positions, sales or procurement positions, etc., and for organization 
units, e.g., larger organization unit, smaller organization unit, staff unit, committee, 
and board (e.g., board of directors). These organizational entities can be connected 
with different types of relationships. Figure 14.28 shows the aggregation relation- 
ship and the “superior” relationship as examples. Furthermore, the symbols can be 
enhanced with information regarding the performance of the organizational entity 
or textboxes showing indicators. 

The example in Fig. 14.29 shows a functional organization including the struc- 
ture on management level. In this model, colors were used in order to visualize the 
different organizational levels. The smaller organization unit “board unit” is supe- 
rior to the “board staff’ and is part of the “executive board.” The executive board, 
which is a “board” organization entity, also includes the three management posi- 
tions CEO, CFO, and COO. CEO, CFO, and COO all are superior to other positions. 
The CEO is superior to the management position “Head of sales,” to take one 
example. The “Head of. . .” positions are responsible for larger organization units 
each, e.g., the “Head of Sales” is responsible for the “Sales” organization unit. The 
more detailed inner structures of these larger organization units are not included in 
the example. 



14.5.5 Perspectives 

As already discussed above, perspectives are part of the overall MEMO framework 
and a key concept reflected in DSML in MEMO. However, when comparing with 
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Table 14.7 Comparison of 4EM perspectives and MEMO 



4EM perspective 


MEMO aspect or perspective 


Goals and 
problems 


Goal aspect (in strategy and organization perspective), GoalML as specific 
modeling language 


Business 

processes 


Process aspect (in strategy and organization perspective) 


Actors and 
resources 


Resource aspect and structure aspect (in strategy and organization 
perspective) 


Concepts 


Not explicitly defined. Can be included in DSML 


Business rules 


Not explicitly defined as aspect. Expressed in IS perspective 


Technical 

components 


Resource aspect and structure aspect (in IS perspective) 



4EM, differences exist in the interpretation of the term perspective and the way it is 
used. In 4EM, a perspective is referring to a perspective on the enterprise, while in 
MEMO it is more the perspective of a specific model user group. These two 
interpretations are difficult to compare since the perspective on the enterprise 
potentially could also be the perspective or abstraction required for specific user 
group. However, the “aspects” of MEMO and the perspectives of 4EM seem to be 
quite close. Both modeling approaches consider goals, processes, and structures. 
MEMO’s resource aspect is similar to resources in 4EM’s actor and resource 
model. The following table compares the 4EM perspective with MEMO’s aspects 
of comparable or similar meaning (Table 14.7). 

It should be noted that MEMO’s DSML provides more model component types 
than 4EM which gives MEMO more expressivity but makes the modeling lan- 
guages more complex and more difficult to master. 



14.5.6 Further Readings 



Ulrich Frank summarizes MEMO and the underlying assumptions and thoughts in 
the following journal article: 

• Frank U (2013) Multi-perspective enterprise modeling: foundational concepts, 
prospects and future research challenges, software and systems modeling. 
Online first (http://link.springer.com/article/10.1007/sl0270-012-0273-9) 

Reports describing the MEMO meta modeling language and the different DSML 
are available from the following URL: http://www.wi-inf.uni-duisburg-essen.de/ 
FGFrank / 
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14.6 Open Model Initiative 

14.6.1 Origin! History 

The Open Model Initiative (OMI, http://www.openmodels.at) started in 2008 with a 
feasibility study for creating a community and platform willing to share models 
similar to open source in software engineering. The initiator and driving force of the 
Open Models Community was at that time Dimitris Karagiannis from the Univer- 
sity of Vienna. Due to Karagiannis close relation to BOC Group, a company 
specialized in IT-based management solutions, BOC and its meta-modeling plat- 
form ADOxx have been supportive and linked to the initiative via the OMI 
Laboratory (OMiLAB, http://www.omilab.org) from the beginning. 

The primary goal of the initiative is the “establishment of a community that deals 
with the creation, maintenance, modification, distribution, and analysis of models” 
(Karagiannis et al. 2008, p. 8). 



14.6.2 Purpose 

The open models initiative considers models a key means for knowledge intensive 
business. Sharing models and model content at the same time contributes to sharing 
knowledge captured in the models and helps to increase the level of productivity in 
knowledge intensive business since existing models can be reused or adapted which 
saves time and efforts. 

The purpose of the initiative is not only to involve modeling experts but also 
users of models. With respect to the types of models, there is in principal no 
selection made. However, much effort of the initiative were spent on conceptual 
models, process, or enterprise models, which make the development relevant for 
this book. Since providing access to models free of charge often will not be 
sufficient for facilitating their reuse, knowledge about creation and use of knowl- 
edge and expertise regarding knowledge content and modeling languages are in the 
scope of the initiative. 



14.6.3 Elements of the Approach 



The core constituents of the Open Models Initiative are according to (Karagiannis 
et al. 2008, p. 25) the Open Model Community, Open Model Projects, and Open 
Model Foundations. These three topics are still reflected in the content of the Open 
Models Web site, which forms the open model community platform. 

The community in autumn 2013 primarily consists of members from an aca- 
demic context. The community has an inner organization structure and defined 
processes for its governance. It has a nonprofit organization structure. 
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Open Model Projects are targeting the development of models or reference 
models in a certain domain, and the development of modeling “infrastructure,” 
which includes tools, templates, model transformers, etc. The open model founda- 
tions include modeling languages, procedures for model development and creation, 
and recommendations for environments or algorithms for model analysis and 
transformation. The results of open model projects can be accessed on the commu- 
nity Web site and often incorporate parts of the foundations developed. 

With respect to modeling languages, the community supports existing modeling 
languages, like UML, ER, or EPC. A list of existing languages, the purpose of these 
languages, tool support, and further information is provided. Furthermore, creation, 
use, and distribution of domain-specific languages are supported. When it comes to 
modeling environments, the initiative promotes development and use of environ- 
ments supporting collaboration between different modeling experts and users. The 
community platform provides among other functionality to navigate, browse, and 
retrieve models also a model repository. 



14.6.4 Model Example 

For the Open Model Initiative, we will not include example models, since the 
objective is not to promote a specific modeling language or notation, but to share 
models and model content from various modeling approaches. The current status is 
available at (OMI 2014), presenting 25 modeling methods, which have been 
conceptualized, developed, and deployed by different research groups, located in 
18 universities on four different continents. 



14.6.5 Perspectives 



Since the Open Model Initiative includes different models and modeling proce- 
dures, it is not possible to compare open models in general with 4EM. For this book, 
we downloaded and examined several modeling method implementations of the 
community Web site. It showed that the methods usually did not follow the method 
understanding introduced in Chap. 3; rather, tool support for modeling specific 
aspects of an enterprise and instructions how to use this tool support is available. A 
selected example, a language for modeling IT security, is implemented on ADOxx 
(Fill and Karagiannis 2013), and is available for download on the community Web 
site (Table 14.8). 



14.6.6 Further Readings 

The Open Model Community Web site (http://www.openmodels.at/) provides 
access to existing literature about the initiative. The “Feasibility Study” report is 
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Table 14.8 Comparison of 4EM perspectives and OMI 



4EM perspective 


Open modeling language examples supporting the 4EM perspectives 


Goals and problems 




Business processes 


EPC 


Actors and resources 


To some extent supported in EPC 


Concepts 


UML and ERM 


Business rules 


UML (e.g., using OCL) 


Technical components 


To some extent supported in EPC 



a good source for learning more about the motivation and background of the Open 

Model Initiative: 

• Karagiannis D, Grossmann W, Hofferer P (2008) Open model initiative — A 
feasibility study. University of Vienna, September 2008. Available at: http:// 
cms.dke.univie.ac.at/uploads/media/Open_Models_Feasibility_Study_SEPT_ 
2008.pdf 

• Open Model Initiative (2014) Open model laboratory booklet. University of 
Vienna. Available at: http://www.omilab.org/web/user/booklet/ 

• Fill H-G, Karagiannis D (2013) On the conceptualization of modelling methods 
using the ADOxx meta modelling platform. Enterprise Model Inform Syst 
Architect 8(1); 4-25 



Chapter 15 

Frameworks and Reference Architectures 



Within the field of Enterprise Modeling, substantial work has been spent on 
defining frameworks and architectures. In comparison to EM methods (see 
Chap. 14), frameworks and architectures do not focus on procedures for the actual 
modeling process, notations, or modeling languages, but they address the modeling 
domain or the results of the modeling process. 

Most frameworks were developed within a specific application domain or for an 
enterprise function and structure this domain and function. Typical organizational 
structures and process areas, important concepts, or building blocks of enterprises 
or solution are identified and described, documented, and made available as tem- 
plates or generic models. The intention is to make those elements of previous 
modeling projects available and reusable, which are not specific for a single 
enterprise, but general for a whole industry domain or for an enterprise function. 

Architectures typically focus on building blocks and their relationships, while 
frameworks can have different ambitions, like combining architectures with design 
or modeling procedures or reusable models or model fragments with the way of 
developing them into a specific solution. Both approaches have in common that 
they have to be adapted for the modeling project or the enterprise under consider- 
ation, i.e., they are rather a rough blueprint than a ready-made solution. 

Frameworks and architectures are part of this book, since they might be useful in 
different phases of an EM project. Depending on the intention and the purpose of 
the project, frameworks and architectures could be used: 

• In the scoping phase to help structuring the overall application domain and 
identify, together with the stakeholders in the enterprise, which areas to focus on 

• When designing the “to be” situation to identify potential best practices in the 
domain or to get inspiration for how to structure the overall field 

• In the analysis phase to reuse proven definitions of general concepts in the 
domain, as long as they fit to the understanding in the enterprise under 
consideration. 
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It should be noted that identifying and understanding the problem to be solved by 
an EM project usually is not supported by frameworks and architectures, i.e., 
understanding problems and issues to be considered is prime and should come 
first. Selecting and using frameworks or architectures from the domain can be 
recommendable, but should be the second step. 

From the many existing frameworks and architectures, only a few will be 
discussed in this section: 

• The Zachman framework — a framework providing support to analyze enter- 
prises which during many years was very popular in industry, 

• GERAM — an approach which combines different industrial reference architec- 
tures to a generalized framework, 

• TOGAF — the open group architecture framework. 

We will give TOGAF more room in this chapter than Zachman ’s framework and 
GERAM, since the interest in TOGAF in industry, the public sector, and academia 
seems to be significantly higher than for the other two approaches. Many more exist 
and are covered in the literature, like, e.g., DoDAF (Department of Defense 2007) 
or MODAF (Ministry of Defense 2008). 



15.1 The Zachman Framework 

The Zachman Framework for enterprise architecture was proposed by John 
A. Zachman, a former IBM employee, who developed the framework as tool to 
help analyze enterprises or parts of enterprises. The core idea of the analysis tool is 
that the complexity of an enterprise can be more easily analyzed and captured if you 
use the different perspectives of the stakeholders interested in the analysis result 
and if you classify the enterprise information according to the content of the 
analysis subject. This idea resulted in a two-dimensional matrix consisting of 
perspectives and subject classifications, called “abstractions”, which can be used 
to guide the analysis work. Furthermore, the matrix also provides a classification 
scheme for what Zachman calls “descriptive representations of an enterprise” 
(Zachman 1987). 

The perspectives distinguished in Zachman’ s framework are depicted in 
Fig. 15.1: 

• The owner s perspective. The owner in this context either is the owner of the 
enterprise under consideration or the recipient of the end product produced. The 
latter is relevant if an organization form is considered where many partners 
jointly produce a complex product, like a consortium of partners producing 
a ship. 

• The designer s perspective. The “descriptive representations” in this perspective 
are meant to form the basis for implementing what is desired by the owner, i.e., 
the intermediary between owner’s and builder’s perspective. In an enterprise, 
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Fig. 15.1 Descriptive representations of Zachman’ s framework according to (Zachman 2003) 



Structure 




Process 




Flow 




People 




Events 




Motivation 


What is it 




How does it 




Where is it 




Who is 

responsible for 
operations? 




When does 




Why does 


comprised of? 




function? 




located? 






it happen? 




it happen? 



Fig. 15.2 Abstractions of Zachman’ s framework according to (Zachman 2003) 

this usually is the systematic and conceptual design of the administrative, 
manufacturing, and management processes and structures. 

• The builder’ s perspective. This perspective captures how the design perspective 
actually is to be implemented, which takes into account existing technical or 
organizational constraints. 

• The scope perspective establishes the inner and outer limits of what has to be 
considered in the other perspectives, i.e., what has to be subject of the descriptive 
representations and what is beyond the limit. 

• The out-of-context perspective captures aspects out of the context of the enter- 
prise or product modeled but still in the scope of the modeling project. In an 
enterprise, this could be the actual physical products manufactured, in contrast to 
the design and manufacturing processes and blueprints of these products which 
would be subject of the designer’s and builder’s perspective. 

With the above perspectives as one dimension, the “abstractions” are the second 
dimension of the framework (see Fig. 15.2) and structure the different characteris- 
tics and aspects required to describe the subject under consideration: 

• What the subject or object under consideration is comprised of 

• How it works, i.e., the specification of a process or of the functionality 

• Where the subject or its components are located, i.e., the spatial dimension 

• Who is responsible for what and who performs which work 

• When activities or events happen in relation to each other 

• Why things happen or are performed in the enterprise. This motivational dimen- 
sion usually relates to the strategy 
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Zachman describes the perspectives and abstractions as primitive and compre- 
hensive in the sense that each abstraction and each perspective is different from 
each of the other ones and that no other perspectives and abstractions are needed to 
provide a complete knowledge base about the enterprise. For the single cells of the 
matrix generic models are available which have to be specialized for the enterprise 
under consideration. If different levels of detail are required, they have to be 
modeled within the different cells of the matrix, i.e., the columns are not intended 
to and do not provide a possibility to model different levels of detail. 

In Enterprise Modeling, the Zachman framework can be used as a general 
guideline what to consider in order to not forget certain aspects. However, it implies 
an ambition to reach a certain level of completeness, which is not required for all 
EM purposes. 

The framework has been very popular and widely used in the first decade of the 
2000s. Judging from the decreasing number of publications and experience reports, 
it nowadays is no longer so widely used. One reason for this might be that 
Zachman’ s framework formed the basis for the Technical Architecture Framework 
for Information Management (TAFIM) developed by the US department of defense 
in 1994. TAFIM later formed one of the starting points for TOGAF (see Sect. 15.3) 
which now is widely used in industry and which somehow replaced Zachman’ s 
framework. 

Further readings regarding the Zachman Framework is available on the Web site 
http : / / www . zachmanintemational . c om . 



15.2 GERAM 

The IFAC/IFIP task force on architectures for enterprise integration produced in 
1998 the Generalized Enterprise Reference Architecture and Methodology 
(GERAM) (Williams 1995). GERAM was based on a number of previous devel- 
opments which complemented each other: 

• CIMOSA (Computer Integrated Manufacturing Open System Architecture) has 
been developed in a European project and aims to support the enterprise inte- 
gration. This architechture is based on the system life cycle concept, and offers a 
modeling language, methodology, and supporting technology. 

• GRAI is a methodology which was developed at the University of Bordeaux in 
the 1990s. The methodology includes a graphical modeling technique and 
considers an organization as a complex system consisting of three subsystems: 
the decision subsystem, the information subsystem and the physical subsystem. 

• PER A is a methodology originating from Purdue University (USA) and includes 
a generic list of tasks in a manufacturing plant and a hierarchical functional 
framework for relating them to each other. 

The intention of GERAM was to combine the above described industrial refer- 
ence architectures to a generalized framework with all components needed for 
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Fig. 15.3 Overview to GERAM components (Lillehagen and Krogstie 2008) 



enterprise engineering and enterprise integration. “Enterprise engineering” as a 
term indicates that GERAM is part of an industrially driven initiative which 
considers enterprises as complex systems that can be “engineered” in a similar 
manner as complex products, i.e., for well-known problems or tasks in an enter- 
prise, the processes and structures for solutions to these problems and tasks can be 
predefined and captured as models. These models and their implementation in real- 
world systems form “components” representing the knowledge about an enterprise 
in a certain domain that can be reused if changes in the enterprise or integration with 
other enterprises need to be implemented. 

The GERAM framework consists of eight elements depicted in Fig. 15.3. These 
elements are: 

• The GERA analysis and modeling framework : this framework defines three 
dimensions for identifying scope, subject, and content of Enterprise Modeling: 
lifecycle, instantiation (level of abstraction), and view. The lifecycle dimension 
in GERA consists of the phases identification, concept, requirements, (prelim- 
inary and detailed) design, implementation, operation, and decommission. The 
instantiation dimension basically defines different levels of abstraction, which 
are generic, partial, and particular. The view dimension includes views regarding 
the purpose of the activity (e.g., customer service, management, and control), the 
model content (resource, information, organization, function), the physical man- 
ifestation (e.g., software, hardware), and the means of implementation (human, 
machine). When using these dimensions, enterprise modelers and enterprise 
model users are supported in defining the scope of a modeling project by 
selecting which aspects of the different dimensions are required, in systemati- 
cally modeling the defined scope, and in structuring the modeled knowledge 
about the enterprise. 

• Enterprise Engineering Methodology : the methodologies provided by GERAM 
are meant to describe the process to be performed for every aspect of the 
lifecycle dimension in a generalized way. The methodologies are supposed to 
be applicable regardless of the industry domain concerned and support their 
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users in the process of enterprise engineering and integration, both for 
management-related and engineering-related aspects. 

• Enterprise Modeling Languages: modeling languages define the constructs and 
the notation to be used for expressing enterprise models (see also Sect. 3.1) 

• Generic Enterprise Modeling Concepts : concepts frequently used in Enterprise 
Modeling, engineering, and integration should be consistent throughout the 
different activities. In case these concepts are generic, i.e., not specific for a 
certain enterprise only, they should be defined once in order to allow for reuse. 
Potential ways to define generic EM concepts are glossaries, meta-models, and 
ontologies. GERAM recommends to use meta-models for generic concept 
definition. 

• Partial Enterprise Models capture concepts of certain aspects of GERA that are 
common to many enterprises. These partial models can be considered as reus- 
able parts or even reference architecture which can speed up the modeling 
process by reusing these proven models if suitable for the enterprise under 
consideration. 

• Enterprise Engineering Tools support the process of the different activities in 
enterprise engineering and integration, i.e., analysis, design, reuse, and use of 
enterprise models. 

• Enterprise Modules are building blocks or systems implemented in an enter- 
prise, which can be accessed and utilized in an enterprise or offered as resources 
on the market. Often, these enterprise modules are implementations of partial 
enterprise models. 

• Enterprise Models capture selected aspects of an enterprise in a model (see also 
Sect. 3.1) in a defined EM language. 

• Enterprise Operational Systems usually consist of the hardware and software 
required for operations in a particular enterprise, i.e., they are platform 
supporting operations in an enterprise. 



15.3 TOGAF 



The purpose of this section is to give a brief view on TOGAF 9.1, an architecture 
framework, which originally established in the 1990s and since then evolved as a 
leading standard for developing an Enterprise Architecture (EA). More than 
100,000 downloads, 16,000 certified practitioners, 220 corporate members are in 
touch already with the TOGAF Framework since 2011 (Weismann 2011). 

The section is structured as follows: Section 15.3.1 presents briefly the relation- 
ship between Enterprise Modelling and EA and describes what TOGAF is, where it 
has its origins, and how it evolved over time. Section 15.3.2 focuses on EA and on 
how TOGAF interprets and defines this term. The main components of TOGAF are 
presented in Sect. 15.3.3 with focus on the Architecture Development Method 
(ADM) and the Enterprise Continuum. Finally, a summary of the main character- 
istics of TOGAF is included. 
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15.3.1 Enterprise Modeling and TOGAF 



Business and IT stakeholders in a company have different views of the enterprise 
and, therefore, different viewpoints on its architecture (Glissmann and Sanz 2011). 
Consequently, special techniques for describing enterprise architectures (EA) in a 
coherent way and communicating them with all relevant stakeholders are necessary 
in order to create an integrated perspective of the enterprise. EA models support 
bridging the communication gap between enterprise or IT architects and stake- 
holders from business [5]. In general specific EA models are used to map architec- 
ture descriptions that represent different and/or partial views of the whole EA. For 
instance, 4EM can be used just for specifying important goal components to get an 
overview about the enterprise strategy as well as 4EM can be used to model 
problem issues like described in the case study (see Chap. 6). 

TOGAF stands for The Open Group Architecture Framework and presents a 
“comprehensive architecture framework and methodology, which enables the 
design, evaluation, and implementation of the right architecture for an enterprise” 
(The Open Group 2011). It provides methods, tools, and best practices to support 
the “acceptance, production, use, and maintenance of an enterprise architecture” 
(The Open Group 2011), which can be customized to and implemented in different 
companies for their needs. 

The original version of TOGAF, Version 1, was introduced in 1995 by the US 
Department of Defense Technical Architecture Framework for Information Man- 
agement (TAFIM). After that the Department of Defense gave The Open Group the 
permission to take over the further development of the framework. Since then, more 
than 300 member organizations of The OpenGroup’s Architecture Forum are 
constantly working on TOGAF, adding new features and concepts. 

TOGAF did not always focus on EA. Initially, it included only technical 
architectures (Version 1-7). With the release of Version 8, called Enterprise 
Edition, it also began to cover the business architecture domain. The latest version, 
TOGAF 9.1, was launched in December 2011. All related documentation about 
TOGAF can be obtained from The Open Group Web site, so that the usage is 
encouraged (Harrison and Varveris 2004). 

TOGAF has two main components. The first core component is the Architecture 
Development Method, or the ADM for short, which defines iterative processes for 
developing and maintaining an organization’s enterprise architecture. The Enter- 
prise Continuum is the second core component to TOGAF. It describes a collection 
of reusable assets, called building blocks, which supply architects with reference 
architectures, models, and processes, which can be adopted to create new architec- 
tures (Temnenco 2007). 
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15.3.2 Enterprise Architecture Management in TOGAF 



Before characterizing the four types of architectures, which TOGAF deals with, it is 
essential to define how to understand the architecture concept. “An architecture is a 
fundamental organization of a system embodied in its components, their relation- 
ships to each other, and to the environment, and the principle guiding the organi- 
zation’s design and evolution” (Lankhorst et al. 2009). Lankhorst describes 
architecture in an analogy: 



“ Suppose you contract an architect to design your house . You discuss how 
rooms , staircases, windows, bathrooms, balconies, doors, a roof etc. will be 
put together. You agree on a master plan, on the basis of which the architect 
will produce detailed specifications, to be used by the engineers and builders. 
How is it that you can communicate so efficiently about that master plan? 
We think it is because you share a common frame of reference: you both know 
what a “room” is, a “balcony” , a “staircase” etc. You know their function 
and their relation. A “room” for example serves as a shelter and is connected 
to another “room” via a “door” . You both use mentally an architectural 
model of a house” (Lankhorst et al. 2009). 



No common definition of the term EA has emerged yet. It depends on the 
different point of views. Thus it is mainly related to IT Architecture focusing on 
creating and using IT systems as well as Business Architecture, which concentrates 
on achieving the business strategy by specific, suitable actions (Aier et al. 2008). 
EA is the idea of modeling the elements, roles, responsibilities, and systems, as part 
of the enterprise infrastructure, and their relations. In this sense the capture of all 
behavior that goes on in an organization including processed data, shared tasks such 
as who does what, why everything is done, and where everything is (Harrison and 
Varveris 2004). It is a coherent whole of principles, methods, and models that are 
used in the design and the realization of the enterprise organizational structure 
(Lankhorst et al. 2009). 

There are four architecture domains that are accepted as subsets of an EA 
(Fig. 15.4) and TOGAF is designed to support all of them. 

The Business Architecture defines the business strategy, governance, organiza- 
tion, and key business processes. This architecture addresses the concerns of the 
users, planners, and business managers (Glissmann and Sanz 2011). The Data 
Architecture describes the structure of an organization’s logical and physical data 
assets and data management resources . Its objective is to define the major types of 
data, necessary to support the business. This architecture addresses the concerns of 
database designers and administrators (Glissmann and Sanz 2011). In some orga- 
nizations, Data Architecture is also called Information Architecture. The Applica- 
tion Architecture provides a blueprint for the individual application systems to be 
deployed, for their interactions and their relationships to the core business processes 
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Fig. 15.4 TOGAF architecture domains 



Table 15.1 Summarized architecture types supported by TOGAF (The Open Group 2011) 



Architecture type 


Description 


Business 

architecture 


The business strategy, governance, organization, and key business 
processes 


Data architecture 


The structure of an organization’s logical and physical data assets and data 
management resources 


Application 

architecture 


A blueprint for the individual applications to be deployed, their interac- 
tions, and their relationships to the core business processes of the 
organization 


Technology 

architecture 


The logical software and hardware capabilities that are required to support 
the deployment of business, data, and application services. This includes 
IT infrastructure, middleware, networks, communications, processing, and 
standards 



of an organization. The Technology Architecture describes the physical realization 
of an architectural solution. The logical software and hardware capabilities, which 
are required to support the deployment of business, data, and application services, 
are also defined in this dimension. The four architechture types are summarized in 
Table 15.1. 

Those four dimensions are intimately connected through the relationships 
between the individual meta-model elements. For instance, a data entity (DA) is 
used by a logical application component (AA), which is used by an actor in a 
business process to meet business objectives (BA). TA supports the application 
component (Glissmann and Sanz 2011). 

The idea of Enterprise Architecture Management (EAM) includes the planning, 
transforming, monitoring, and improvement of the different architecture levels. In 
this context, the Enterprise Architecture (EA) serves as map with information of the 
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current situation of its elements and dependencies. There is a variety of reasons for 
implementing EAM: 

• It supports delivery of the business strategy 

• It facilitates management and exploitation of information is key to business 
success and competitive advantage 

• It facilitates management of stakeholder concerns that needed to be addressed by 
IT systems 

• It enables management of complexity and changes to business/IT 

• It enables the right balance between IT efficiency and business innovation 

• It improves transparency and manage risks 

TOGAF also helps implementing a strategy oriented control of the different 
architectural levels, which enables economic success. 



15.3.3 Components of TOGAF 9.1 

TOGAF 9.1 consists of seven parts presented in the following parts of this section. 



15.3.3.1 Part 1: Introduction 

The first part of the TOGAF framework involves the introduction the EA key 
concepts. Therefore, it contains the definitions of terms used throughout TOGAF 
and release notes detailing the changes between the different versions of TOGAF. 
Questions like “What is an enterprise? Why do I need an enterprise architecture? 
Why do I need TOGAF as a framework for enterprise architecture?” will be 
answered in this section. 



15.3.3.2 Part 2: The Architecture Development Method 

The architecture development method (ADM) is a step-by-step approach to develop 
and use an EA. The main purpose of the approach is to help to derive a specific 
architecture from a set of common architectures to meet the business requirements 
of an enterprise (Josey et al. 2009). The ADM supports the development of an 
architecture in the four different domains (business, application, data, and technol- 
ogy), described in the previous section. It consists of ten consecutive phases (see 
Fig. 15.5) enclosed in a loop (Temnenco 2007). 

Each phase has an input, an output, which at the same time serves as an input for 
the next following phase, and a number of steps. In the following these phases will 
be described briefly: 
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Fig. 15.5 The architecture development method cycle (The Open Group 2011) 



• Preliminary Phase: The main goal of this phase is to prepare the organization 
and get the stakeholders ready for a successful TOGAF project. Typical steps of 
this phase are defining the scope of the enterprise, establishing the team and the 
organization, and determining the architecture principles. 

• Phase A: Architecture Vision: Phase A is dedicated to articulating the EA vision 
and principles, and presents the initial phase of the architecture development 
cycle. Its most crucial objectives are to obtain a management commitment for 
this particular cycle of the ADM and to validate business principles, goals, and 
key performance indicators. During the preliminary phase and Phase A, it must 
be clarified, how much information will be captured, how it will be maintained, 
what notations or methods are used to build the enterprise models. 
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• Phase B: Business Architecture (BA): Phase B describes the current and the 
target business architecture and tries to determine the gap between these two. 
The motivation for developing a BA is to support the Architecture Vision which 
was agreed upon in the previous phase. Adequate tools which can be applied in 
this phase in order to develop the required models are, e.g., BPMN and UML 
(Harrison and Varveris 2004). 

• Phase C: Information Systems Architectures: Phase C focuses on the Informa- 
tion Systems Architectures, which comprise the Data and Application Architec- 
tures. These architectures can be developed either sequentially or concurrently 
(Josey et al. 2009). In this phase, business-supporting data types and sources are 
to be described in such a way that the stakeholders understand them. Hencefor- 
ward, the application systems, which can process the data, are to be defined. 

• Phase D: Technology Architecture: Phase D deals with documenting the orga- 
nization of the IT Systems, embodied in the enterprise hardware, software, and 
communication technology. The completion of Phases B and C is a prerequisite 
for moving on to Phase D. The development of all four architecture domains are 
covered after the Phases B, C, and D are finished. 

• Phase E: Opportunities and Solutions: Phase E is the first phase, which is 
directly concerned with implementation (Josey et al. 2009). It has two main 
purposes — to clarify the opportunities presented by the target architectures, 
which have been identified in previous phases, and to outline the potential 
solutions. The important outputs of this phase are a major implementation 
project and an updated Application Architecture which can serve as a blueprint 
to be used by future implementation projects. 

• Phase F: Migration Planning: The proposed implementation projects need to be 
prioritized so that a detailed planning can be performed. In this phase the 
enterprise knows how to move from the baseline to the target architecture by 
finalizing a detailed Implementation and Migration Plan. The blueprint, devel- 
oped in the previous phase, is also handed over to the implementation teams. 

• Phase G: Implementation Governance: In phase G, the projects are started as a 
planned program of work that is accompanied by implementation process 
oversights. 

• Phase H: Architecture Change Management: Phase H provides a change man- 
agement process to ensure that the designed architecture corresponds to the 
needs of the enterprise. If the enterprise needs change then these changes will 
be realized in the architecture in a controlled and procedural manner. Phase H 
can also result in a request for a new architecture framework and, if so, another 
cycle of the ADM is initiated. 

• Requirements Management: The Requirements Management process applies to 
all phases of the ADM cycle because TOGAF is a requirements-centric approach 
(Temnenco 2007). Generally, architecture deals with change and uncertainty in 
requirements, since it bridges the gap between the expectations of the stake- 
holders and delivered solutions. That is why Requirements Management has a 
central meaning to TOGAF. This phase defines and stores all types of require- 
ments, and feeds them in and out of the relevant ADM phases (Josey et al. 2009). 
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15.3.3.3 Part 3: ADM Guidelines and Techniques 

This part provides a set of guidelines and techniques to support the application of the 
ADM. It deals with different scenarios, including different process styles (e.g., the 
use of iteration) and also specific requirements (e.g., security). The techniques 
support specific tasks within the ADM (e.g., defining principles, business scenarios, 
gap analysis, migration planning, risk management, etc.). 

According to (The Open Group 2011; Keller 2012) the third part deals with the 
following issues: 

• Using ADM as a cyclic process. This is about managing iteration and the 
potential strategies for applying iterative concepts to the ADM. 

• Applying the ADM across the Architecture Landscape. It is about the different 
types of architecture engagement that may occur at different levels of the 
enterprise. It is also about how the ADM process can be focused to support 
different types of engagement or levels of granularity. 

• Doing security engineering while using TOGAF. An overview of specific 
security issues that should be considered during different phases of the ADM 
is provided as well as aspects of using TOGAF for SOA support, stakeholder 
management, or architecture patterns. 



15.3.3.4 Part 4: Architecture Content Framework 

The Architecture Content Framework provides a detailed structural model for 
architectural content that allows the major work products including deliverables 
and artifacts within deliverables that an architect creates to be consistently defined, 
structured, and presented in Architecture Building Blocks (ABBs). The fourth part 
supports the following aspects: 

• Increasing the consistency in the outputs of TOGAF. 

• Providing a comprehensive checklist of architecture outputs. 

• Promoting better integration of work products. 

• Providing a detailed open standard for how architectures should be described. 

• Including a detailed meta-model (see Fig. 15.6) 



15.3.3.5 Part 5: Enterprise Continuum and Tools 

The Enterprise Continuum (EC) is “a categorization mechanism useful for classi- 
fying” all assets relevant to an enterprise. The result of its practical implementation 
is an Architecture Repository which presents a collection of “reference architec- 
tures, models, and patterns that have been accepted for use within the enterprise” 
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Architecture Principles, Vision and Requirements 




Business Architecture 



Information System Architecture 



Technology Architecture 



Motivation 



Organization 



Function 



Data 



Application 



Application Realization 



Opportunities, Solutions and Migration Planning 



Implementation Governance 



Fig. 15.6 Content meta-model (simplified) (The Open Group 2011) 



(The Open Group 2011). The EC focuses strongly on the two ideas of reusability 
and understandability. 

Reusability is achieved through the concept of the building blocks. A building 
block (BB) is “a (potentially reusable) component of business, IT, or architectural 
capability that can be combined with other building blocks to deliver architectures 
and solutions” (The Open Group 2011). The delivered architectures and solutions 
can then be used in two directions: (1) the general ones can be adapted to fulfill 
specific needs and (2) the specific ones can be generalized for further reuse. 

The idea of understandability is achieved through two concepts. The first one is 
the concept of sequentially moving from generic to specific, from abstract to 
concrete, which helps everybody involved in the architecture development process 
to understand where exactly they are in the continuum and which type of architec- 
ture is currently in focus. The second concept is the separation between architec- 
tures and solutions — the EC is divided into two continua, the Architecture 
Continuum and the Solutions Continuum. 

The Architecture Continuum (AC) is “a repository of architectural elements with 
increasing detail and specification” (The Open Group 2011) and has four states: 
foundation architectures, common systems architectures, industry architectures, 
and organization- specific architectures. 

Foundation Architectures present architectures of building blocks and 
corresponding standards that support all the Common Systems Architectures and, 
therefore, the complete enterprise operating environment. 

Common Systems Architectures are architectures of particular problem domains 
within an organization. Examples of such architectures are security architectures, 
management architectures, network architectures, etc. 

Industry Architectures are architectures that integrate common systems with 
industry- specific components to create solutions to problems within a particular 
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industry. Such architectures contain industry-specific logical data, industry- specific 
process models and applications, and industry -specific business rules. 

Organization-Specific Architectures contain organization-specific business 
models, data, applications, and technologies. They reflect requirements and define 
BB specific to a particular enterprise, and provide the criteria to measure and select 
appropriate products, solutions, and services. 

The Solution Continuum (SC) provides particular solutions to implement the 
corresponding architectures from the AC. 

Therefore, the SC has also four states as the AC: Foundation Solutions, Common 
Systems Solutions, Industry Solutions, and Organization- specific Solutions. 

The solutions are developed with the help of Solution Building Blocks (SBB), 
which, just as the ABB, increase in detail and specification in each state. 

The SBB include concepts, tools, products and services such as programming 
languages, operating 10 systems, ERP- Systems, IT Organization-Management 
standards and principles such as ITIL, and others. 



15.3.3.6 Part 6: TOGAF Reference Model 

Part 6 of the TOGAF Framework provides two reference models: 

1. The Foundation Architecture/ Technical Reference Model (TRM) 

2. The Integrated Information Infrastructure Model (III-RM). 

The foundation architecture provides an architectural approach of generic ser- 
vices and functions which should support building more specific architectures and 
architectural components. The foundation architecture is embodied within the 
universally applicable TRM that represents a model and taxonomy of generic 
platform services (Fig. 15.7). 

The III-RM is defined as a subset of the TRM in terms of its overall scope. It 
supports the design of an integrated information infrastructure by defining a taxon- 
omy concept and associated visual representation of the interrelationship of its 
components. According to (The Open Group 2011) the main objective of the 
TOGAF TRM is the allocation of a widely accepted core taxonomy and an 
appropriated visual representation of them. 



15.3.3.7 Part 7: Architecture Capability Framework 

This part discusses the organization, processes, skills, roles, and responsibilities 
required to establish and operate an architecture practice within an enterprise as 
well as provide guidance on establishing an operational practice. In order to achieve 
TOGAFs view on successfully operating architecture functions, it is necessary to 
put in place appropriate organizational structures, processes, roles, responsibilities, 
and skills to realize the Architecture Capability. In this section of the TOGAF 
Framework, a set of reference materials for how to establish such an architecture 
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Fig. 15.7 TRM overview 
(simplified) (The Open 
Group 2011) 




function is presented. The Architecture Capability Framework is not intended to be 
a comprehensive template for operating an enterprise Architecture Capability; it 
provides a number of guidelines to support key activities (The Open Group 2011). 



15.4 Summary 

This session introduced TOGAF — The Open Group Architecture Framework in its 
latest version, Version 9. 1 . It gave a brief insight into components of TOGAF where 
the ADM is the very core of TOGAF. TOGAF covers the whole lifecycle of EA and 
EAM — from the idea, covered in the Architecture Vision (Phase A), to the control 
of changes, handled in the Architecture Change Management (Phase H). 

In addition to this, through the Requirements Management, new external drives, 
especially business strategies and requirements, can be added to the architecture 
during the whole lifecycle. The EC presents a virtual repository of architecture 
assets which evolve from generic to specific and can be adopted to develop a target 
architecture by starting with a common architecture and finishing with one, specific 
to the organization. 

TOGAF provides a very interesting approach to EA and EAM which can help 
solve many different problems in an organization. It has the potential to help 
organization to deeply examine their organization, to understand how it currently 
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operates, and to define how it must function. It encourages stakeholders and 
management to work together in order to achieve the desired organization. How- 
ever, TOGAF is a very complex framework and its use requires thorough prepara- 
tion. Only reading its documentation and visiting several workshops will not 
sufficiently prepare for dealing with TOGAF. This view is also shared in (Sessions 
2007). There the author argues that TOGAF focuses on how to develop an EA and 
not on how to develop a good one. Therefore, the final architecture can either be 
good, bad, or indifferent. The result completely depends on the knowledge and 
skills of the TOGAF architects. 

In addition, it is recommendable for TOGAF users to find access to communi- 
cation platforms, where they can exchange knowledge, thoughts, ideas, and expe- 
rience with others on different EA and TOGAF matters. 




Chapter 16 

Outlook 



This book focuses on the fundamentals of Enterprise Modeling and has, in the 
preceding chapters, dealt with such topics as elicitation approaches, tools, quality 
aspects, and the 4EM method as a practical approach. However, the field of 
Enterprise Modeling is considerably broader than is possible to cover fully in an 
introductory book. This chapter is intended to provide an overview of a range of 
issues and additional content, including further technical aspects, additional ways 
of using models, and fields of application for Enterprise Modeling. 



16.1 Further Technical Aspects 

Several technical aspects of Enterprise Modeling could only be touched upon in this 
book, and not dealt with in full. These include meta-modeling, additional possibil- 
ities for quality assessment, and specific modeling tools. 

Put simply, meta-models are descriptions of modeling languages. The technique 
of meta-modeling deals with developing modeling languages or adapting existing 
languages. Modeling language development aims to provide the necessary model 
components, symbols, and views for particular domains or requirements in a well- 
defined language. These special languages, also known as domain specific lan- 
guages (DSLs), are intended to facilitate modeling and model comprehension for 
domain experts from the respective domain by providing only the modeling 
types and views that are needed. An example of this would be a specific language 
for public administration, which distinguishes “procedures” instead of “processes” 
and does not require component types for modeling product structures. The disad- 
vantage of DSLs is that tool support for languages of this kind is often not as good 
as for general and more widely used languages. Meta-modeling to adapt existing 
languages frequently aims only at altering the symbols for individual component 
types or to modify the component type attributes. In this case, the properties of the 
original language are not fundamentally changed, and the tools can continue to be 
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used. Further literature on meta-modeling can be found in scientific journals or 
conference proceedings, such as the International Conference on Model Driven 
Engineering Languages and Systems (MODELS), 1 IFIP WG8.1 Working Confer- 
ence on the Practice of Enterprise Modeling (PoEM), 2 the International Conference 
on Business Process Management (BPM) 3 conference proceedings, as well as the 
journal “Business & Information Systems Engineering”. 4 

With regard to assessing the quality of enterprise models, Chap. 1 1 of this book 
particularly dealt with modeling tips and practices, such as generally accepted 
modeling principles. However, there are also numerous other works that consider 
both the quality of models themselves and the quality of their use. A number of 
metrics for measuring the quality of models were suggested to help assess their 
complexity, completeness, comprehensibility, correctness, or maintainability. A 
summary of such metrics for process models can be found, for example, in 
(Mendling 2008). When using metrics of this kind, it is important to be aware that 
the measurements provide only indications as to quality, and do not by any means 
definitive statements, as ultimately the intended use and modeling object are key. 

There are also a number of developments for evaluating the quality of models 
during their use. These consider how suitable the model is for the planned purpose 
from a usage perspective, how complex or efficient the model is to use, what errors 
or extensions are found when using the model, or how useful a model is compared 
to the time spent creating it. The SEQUAL framework (Krogstie 2012) is an 
example of a quality assessment framework in this field. 

The field of tool support in Enterprise Modeling was discussed in Chap. 5 of this 
book with the aim of providing an overview of tool types and their functions. There 
are also numerous other categories of computer-based tools, which essentially 
cover all phases of modeling and offer special functions for particular areas of 
application. There are, for instance, modeling tools that generate models from the 
data available in information systems, or that import from data flow or process 
models into enterprise models. Once a model has been created, there are a number 
of test programs (called model checkers) and tools to facilitate the publication of 
models and their integration into documents. The tool categories for particular areas 
of application include tools for enterprise architecture management, workflow 
management, document management with integrated process control, or product 
data management, to name just a few examples. Further information on this area 
can be found in tool studies by consulting firms or industry associations. 



1 See http://www.modelsconference.org/ 

2 See https://research.idi.ntnu.no/ifip-wg81/english/events 

3 See http://www.bpm-conference.org/ 

4 See http://www.bise-joumal.com/ 
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16.2 Use of Models 

Chapter 8 looked in detail at the development of different enterprise model per- 
spectives, but did not cover all options for further model use. For some application 
scenarios, the models are suitable as they stand, without further changes. They 
include, for example, using the models as a “blueprint” for organizational changes 
or as a description for employees as to how processes should be carried out or how 
structures should look in the enterprise. However, the models must be refined 
further in order to introduce workflow solutions or begin developing software 
solutions. 

The aim of workflow solutions is to support process performance by making the 
tasks to be carried out automatically and made available to individual roles, along 
with the necessary information, via a software component called the workflow 
engine. Once completed by a user, the next of the process defined during process 
modeling would then be triggered. For use in workflow management, enterprise 
models must be further developed with regard to the level of detail and formaliza- 
tion of the process model. There are modeling languages that have been specially 
developed for workflow applications, such as BPMN 5 and BPEL, 6 into which the 
relevant parts of the enterprise model must then be converted. Although closely 
related, workflow management is not considered as a branch of Enterprise Model- 
ing, and features numerous specialist publications such as Weske’s work on the 
subject (Weske 2012). 

In the context of software development, enterprise models play an important role 
inasmuch as the context in which the software will be used is described in the model 
of the future target situation for an enterprise. This is part of the definition of 
requirements. It includes the processes that should be supported by software 
(corresponding to use cases in software engineering), the various roles that should 
use the software (i.e., user groups), or even the requirements explicitly modeled in 
The Technical Components and Requirements Model of 4EM. Moreover, the 
Concepts Model in 4EM is generally suitable for use at least as a precursor to the 
information model, and in fact it is often the first version of it. Depending on the 
development method, the use of Enterprise Modeling that results in software 
development requires the use or further development of models, not conversion 
of models. Further information on software engineering can be found, for example, 
in the textbook by Sommerville (2010). 

Recently, organizations have been facing an increased need to adhere to changes 
in their business environment, which also requires adjustments of the supporting 
information systems. Since predicting all application contexts in advance at design 
time is difficult, this in essence requires tailoring enterprise designs and 
implementing the required application changes at run time. To this end a new 
approach called Capability Driven Development (CDD) has been proposed in 



5 BPMN = Business Process Model and Notation, see http://www.bpmn.org 

6 BPEL = Business Process Execution Language. 
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Fig. 16.1 Outlook on the capability driven development methodology 

Stima et al. (2012). From a business perspective, a capability is the ability to 
continuously deliver a certain business value in dynamically changing circum- 
stances. Key aspects of capability design are that it (1) considers the application 
context (modeled with context models); (2) bases capability designs and delivery 
on best practices captured in the form of patterns, as well as (3) incorporates 
algorithms for capability delivery adjustments at run time. 

CDD is currently elaborated to become a comprehensive development method- 
ology with tool support under the FP7 project CaaS — Capability as Service in 
digital enterprises (proj.no 61 1351). 7 

Figure 16.1 shows an overview of the envisioned development process where 
Enterprise Modeling takes an important first step towards capturing and making 
explicit the business design. More specifically, Enterprise Modeling, using the 4EM 
method, will be used for defining the overall business design that will serve as input 
for the capability design. Capabilities will be designed to reach business objectives 
and hence, the interrelations between objectives, strategies, organizational struc- 
tures, and processes are to be captured in enterprise models. The capability design 
will explicitly focus on evaluation of different business service designs in various 
delivery contexts and capabilities which will be customized to specific 
requirements. 

The Capability delivery phase concerns the actual utilization of the capability 
enabled by supporting information systems (i.e., capability delivery environment) 
with the intention to meet the organization’s business goals in continuously 



7 See http://caas-project.eu/ 
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evolving circumstances. The approach will also consist of activities for project 
management and feedback collection. More about the CDD approach is available in 
(Zdravkovic et al. 2013; Berzisa et al. 2014). 



16.3 Areas of Application 

Among the application areas for Enterprise Modeling that this book has not 
discussed are architecture management and knowledge management. Enterprise 
architecture management (EAM) arose from the insight that, firstly, the number and 
complexity of information systems and IT solutions are constantly growing and 
must be coordinated and controlled in the interest of efficient IT management, and 
secondly, IT support is becoming increasingly important for many enterprises, and 
hence it is essential to understand how the enterprise’s processes and structures are 
related to the IT solutions that support them. Enterprise models contain the infor- 
mation about interrelations and dependencies between processes, organizational 
structures, and systems that is necessary for this understanding. However, they do 
not provide the detailed information about each individual application or IT system 
that would be required in order to manage these in the long term, to plan further 
developments, or to analyze areas of risk, cost structures, and potential for devel- 
opment. In this respect, EAM has emerged as an important area of application for 
Enterprise Modeling. Further information can be found, for example, in (Ahlemann 
et al. 2012). 

How particular processes can best be carried out and what is the most sensible 
arrangement of organizational structures could be considered as part of enterprise 
knowledge. Viewed from this perspective, enterprise models, since they model 
enterprise knowledge, should consequently be included in an organization’s knowl- 
edge management activities. This area of application is attracting great interest in 
industry and research, which has led to the development of special methods and 
tools, such as the concept of “active knowledge modeling” introduced in Lillehagen 
and Krogstie (see also Sect. 14.1). The principle behind this is that models, once 
developed, are to be used by enterprise employees in their day-to-day work and thus 
constantly should be and updated. This avoids a situation where models over time 
no longer reflect the real situation in the enterprise. It also ensures that enterprise 
knowledge is present in models and available to domain experts within the enter- 
prise for strategic, innovation, or improvement purposes when needed. However, 
this manner of using models is highly demanding in terms of the involved 
employees’ skills. It also requires tool support functionality that allows the models 
to be accessed and used throughout the enterprise. To date, active knowledge 
modeling has only proved successful in practice for a few knowledge-intensive 
enterprise functions and roles. 
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16.4 The Art of Facilitation 

Chapter 10 of this book addresses issues related to Enterprise Modeling practitioner 
competence. A number of the core competences were discussed in relation to 
different activities in an Enterprise Modeling project and in relation to different 
purposes of modeling. One of the core competences is the ability to facilitate 
modeling sessions, which means that a person is able to lead a group of domain 
experts in creating/refining an enterprise model and doing it in such a way that the 
group’s knowledge and abilities work together to create a high quality model. 
Participatory Enterprise Modeling, as advocated by the 4EM approach, includes 
the activities of preparing modeling sessions, facilitating them and documenting the 
result. 

As was mentioned in Chap. 10, facilitation is a general technique used in group 
processes for a wide variety of purposes, also within Enterprise Modeling (see 
further, e.g., Zavala and Hass 2008) and International Association of Facilitators 
(IAF). 8 

When talking to Enterprise Modeling practitioners about competence require- 
ments for facilitation of modeling sessions, they often mention “social skills” as one 
such requirement. These “social skills” are personal characteristics, some of which 
can be further described as in the following sections (Astrakan 2001). Becoming a 
skilled facilitator requires a great deal of practice and dedication. In the context of 
Enterprise Modeling facilitation does not, however, only relate to the social skills of 
the facilitator. Apart from dealing with the group processes in a multitude of 
different situations, the facilitator is also responsible for the quality of the models 
produced both in terms of their “correctness” and in terms of their usefulness for 
whichever purpose they are intended. 

There is not much literature on facilitation in Enterprise Modeling although 
some information on the topic can be found in (Nilsson et al. 1999). As of now the 
novice modeling practitioner is to a large extent dependent on access to more 
experienced colleagues for advice and feedback, which is risky since the novice 
can make many costly mistakes in the process of learning. This is something for an 
organization to take into account when adopting Enterprise Modeling (Chap. 11). 

16.4.1 Listening Skills 

Listening is not only about listening to what is actually being said. Listening behind 
the words for what is really meant is essential here. A practitioner once described 
the importance of taking on his “elephant ears”. 



8 See http://www.iaf-world.org 
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16.4.2 Group Management and Pedagogical Skills 



The leader role is facilitated by the ability to motivate and to keep the modeling 
participants interested. The ability to detect and solving potential conflicts is also 
part of this skill. 



16.4.3 Act as an Authority 

To be an authority in this context is not the same as being authoritative. To act as an 
authority is to create trust for your own competence and to make the modeling 
participants feel that you know what you are talking about. 



16.4.4 Courage and Ability to Improvise 

Many experienced practitioners emphasize that courage is a desired personal 
characteristic in a modeling facilitator. Courage in participatory Enterprise Model- 
ing is about not being afraid of unknown situations. Not everyone accepts entering 
into the unknown, owing to her/his personality. Others are too inexperienced to 
cope with this type of situation. This characteristic relates to the issue of problem 
complexity, particularly the notion of “wicked problem,” since such problems have 
many unknown variables. 
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